Code review: мысли и факты

Code review

• регулярный code review делают меньше 50% команд shepard/492/ppt/ppt18.ppt
• 96% дефектов выявляется при просмотре кода в одиночку (не на формальном митинге) http://dl.acm.org/citation.cfm?id=167070
• количество ревьюеров не должно быть большим http://blog.smartbear.com/code-review/who-should-review-my-code/
• одиночный ревьюер находит примерно 50% дефектов, два ревьюера - примерно 75% http://www.leshatton.org/Documents/checklists_in_inspections.pdf
• разработчик, который перепроверяет свой же код, также находит примерно 50% дефектов http://smartbear.com/resources/whitepapers/best-kept-secrets-of-peer-code-review/
• количество проблем, обнаруженных во втором code review, составляет примерно 50% от количества найденных в первом, команды из 3-4-5 ревьюеров практически не дают преимущества перед двумя ревьюерами http://dl.acm.org/citation.cfm?id=331521
• code review проводится не новичками, но для новичков
• эффективность ревью сильно зависит от уровня ревьюера и его знания просматриваемого кода http://dl.acm.org/citation.cfm?id=331521
• лучшие разработчики, тим-лиды и архитекторы могут и должны тратить время на code review
• соответствие кода стандартам кодирования/форматирования должно проверяться автоматически до ревью
• наибольшее время в ходе ревью уделяется проблемам сопровождаемости и читаемости кода: поиск ошибок в чужом коде намного сложнее, чем поиск ошибок в своём, сначала его надо прочитать и понять http://dl.acm.org/citation.cfm?id=1592371 http://www.st.ewi.tudelft.nl/~mbeller/publications/2014_beller_bacchelli_zaidman_juergens_modern_code_reviews_in_open-source_projects_which_problems_do_they_fix.pdf
• некоторые компании проводят двухэтапное ревью: первый этап - зачистка, поиск и исправление проблем форматирования/читаемости, второй этап - собственно глубокое ревью
• можно выделить наиболее критические участки кода или изменения и проводить их ревью более тщательно

Глубина стека JavaScript (дубль 2)

Продолжение (первая часть здесь).

На http://www.2ality.com/2014/04/call-stack-size.html натолкнулся на мысль, что измеряемая глубина стека зависит от размера фрейма (который может зависеть от локальных переменных и аргументов функции). Дополнил скрипт, заодно для наглядности вставил рисование графика глубины стека в зависимости от количества аргументов/локальных переменных. Результат:

Кол-во
аргументов/     0/0    1/0    1/1    1/2    1/3
переменных

Chrome 39:      41962  31472  27975  25178  22889  ±50
Chrome 36:      20986  15740  13991  12592  11447  ±50
Safari 5.1.7:   65532  58250  52425  47659  43688
Opera 12.17:    32624  31505  32691  31478  31419
Opera 17:       21002  15752  14002  12602  11456  ±50
IE9 (IETester): 24789  20657  20657  20657  20657
IE11:           32000..62000 не зависит от кол-ва переменных
Firefox 20:     27000..52000 не зависит от кол-ва переменных
Firefox 31:      6600..21000 не зависит от кол-ва переменных

Результаты для IE11 и Firefox не зависят от количества локальных переменных/аргументов, и сильно изменяются от запуска к запуску.

Результаты для Chrome и новой Opera незначительно изменяются после первого запуска, далее остаются постоянными.

Programs for batch image optimization

Collection of image optimization programs is growing. Currently it includes:

• OptiPNG/Linux 0.6.4
• OptiPNG/Windows 0.7.5
• PNGOUT
• GIF Optimizer
• Gifsicle
• JPEGTran

Social software: A Group Is Its Own Worst Enemy

A Group Is Its Own Worst Enemy

Learning from experience is the worst possible way to learn something. Learning from experience is one up from remembering. That's not great. The best way to learn something is when someone else figures it out and tells you: "Don't go in that swamp. There are alligators in there."

• Groups of people are aggregations of individuals or a cohesive group? Hopelessly committed to both.
• Uncontrolled groups tend to defeat their goals via sex talks, identification and vilification of external enemies, religious veneration etc.
• Constitutions are a necessary component of large, long-lived, heterogeneous groups.
• You cannot completely separate technical and social issues.
• Members are different than users.
• The core group has rights that trump individual rights in some situations.
• Social software should have the handles the user can invest in ("identity").
• Social software should have some way in which good works get recognized.
• Social software should have to have some cost to either join or participate, if not at the lowest level, then at higher levels.
• Social software should have a way to spare the group from scale.

Как MSBuild.Exec определяет ошибки при запуске third-party tools

При подготовке дистрибутива почти любого проекта возникает необходимость выполнить в качестве одного из этапов сборки произвольную программу (минификатор скриптов, архиватор, создание инсталлятора и т.п.), и желательно, чтобы при ошибках в её выполнении сборка останавливалась.

Как это реализовано в MSBuild: Exec Task - Runs the specified program or command by using the specified arguments.

У Exec есть одна особенность, о которой в документации прямо не упомянуто: "умное" определение ошибок выполнения. Если выполненная программа завершилась с ненулевым кодом, то Exec считает это ошибкой, но если программа завершилась с нулевым кодом, то Exec дополнительно сканирует её вывод (stdout, stderr) на наличие ключевых слов.

Generics in JSDoc

/**
 * @interface
 * @template T
 */
MyEnumerable = function () { };

/**
 * @param {T} item
 */
MyEnumerable.prototype.add = function (item) { };

/**
 * @constructor
 * @template TItemType
 * @extends {MyEnumerable.<TItemType>}
 */
MyList = function () { };

/**
 * @param {TItemType} item the item
 */
MyList.prototype.addItem = function (item) { };

/** @type {MyEnumerable.<string>}*/
var enumerable = new MyList();
enumerable.add("Bob"); // correct
enumerable.add(123); // correct warning: number is not assignable to type string 

/** @type {MyList.<string>}*/
var list = new MyList();
list.add("Bob"); // incorrect warning: number is not assignable to type TITemType 
list.addItem("Bob"); // correct

Now works in WebStorm

Chrome 33: null !== null (sometimes)

Если в Chrome 33 посмотреть в консоль на страничках http://jsfiddle.net/u42Xm/1/ и http://jsfiddle.net/u42Xm/2/ то увидим интересную картину: условие null === null не выполняется 26440 раз из 50000 проходов цикла. Баг оптимизатора?