January 30th, 2013

404

Из комментов на хабре

Просто для понимания, одна-единственная мелкая тема — ipv6, состоит из всего лишь из 43 актуальных RFC (и ещё примерно сотни obsolete, которые ещё надо уметь отличать от актуальных), в которых всего-навсего 144 тысячи строк (422 тысяч слов). Просто для понимания масштаба, в войне и мире всего 180 тысяч слов.

Считалось wget/wc с IETF'а. Список актуального - http://www.gogo6.com/profiles/blogs/ipv6-rfcs
404

code review

(фрагменты мыслей)

Code review является множителем для проекта. Условно говоря (цифры нормируются произвольно), если у нас проект имеет ценность 10, а code review даёт нам x1.2, например. В этом случае полезность проекта будет 12.

Отсюда и понятна ситуация с code review - чем крупнее проект, тем выше его эффективность. Если у вас полезность проекта 1, то получите вы на выходе 1.2.

... затраты.

А вот затраты на code review крайне значительные.

Впрочем, сначала о типах code review.

В code review на самом деле включается три значительных составляющие:
* анализ стиля, оформления, соответствия духу проекта (может касаться чего угодно - от формата новых запросов в API до негласного правила использования только старших битов для флагов в syscall). Любые ошибки на этом этапе легко исправляются.
* проверка соответствия ТЗ. Обычно состоит в том, что проверяющий читает ТЗ и код, и проверяет, что и там и там написано одно и то же (это не детальная проверка "есть баги или нет", это общая проверка на вменяемость кода, потому что бывает, что человек просто "не так понял". В принципе, на этом этапе могут быть пойманы какие-то забавные баги, которые заинтересовали читающего.

И, наконец, третья составляющая. Это проверка вменяемости кода. По результатам обсуждения его мы решили называть не "херня", а "экстравагантный код". Яркий пример: SELECT * FROM ; с последущющей сортировкой пузырьком. Оно в прнципе работает, но является крайне ху.. экстравагантным решением, и принесёт проблемы потом.

И именно третье является главной задачей code review, как концепции. (Вторая важная задача - кросс-обучение работающих над проектом программистов, но это не фактор качества, а фактор скорости).

Однако, вернёмся к цене удовольствия. code review первых двух типов (а правильнее говорить, что первые два пункта это и есть простое code review) требуют мало времени. Более того, результатом code review является "сделана" задача или "не сделана" (если в коде полная фигня, не имеющая отношения к ТЗ). Польза от такого code review тоже не особо большая. В принципе, есть, но весьма ограниченная.

Третья часть code review требует итеративного переписывания. Если в процедуре участвуют несколько человек, то нужно учесть значительные замечания обоих. То есть требует совершенно неизвестного времени, которое состоит из:
времени написания кода
времени прочтения кода x число рецензентов
времени на написание претензий
времени на переписывание кода
времени на споры о том, надо или нет

Причём последнее во-первых итеративно (то есть "сколько раз" совсем не понятно), а во-вторых может отъедать время ещё и других людей, привлекаемых в качестве арбитров в споре (а сами споры очевидно нужны, особенно в отсутствие явной иерархии senior-junior, ибо в ходе грамотной дискуссии учатся все участвующие стороны, и даже просто слушающие и понимающие о чём речь).

Польза от такого code review огромная, потому что именно оно является мультипликативным фактором. Оно создаёт основу для чистого кода, который легко поддерживать, который адекватнее работает при сдвиге в экстремальные области, с меньшей вероятностью содержит wft багофичи. Не говоря уже про фактор роста квалификации.

Но время...

Впрочем, вернёмся к исходному. Имеем мультипликативный эффект на код. И кратные (неизвестной кратности) временные затраты команды.

Таким образом, третий тип review оказвается губительным для малоценных проектов. Если без code review он просто малоценный, то с code review его польза вырастает незначительно, а вот затраты - гарантированно кратно. И, наоборот, пропуск code review для очень ценного кода означает, что утрачена возможность значительно повысить его ценность за разумную и малую цену.

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

PS Если вы хотите такого, да ещё и на haskell/erlang, то welcome к нам, в Селектел.