Один на один

Вы показываете свой код для критического анализа другому про% граммисту. Тот проверяет логику и смотрит, нет ли ошибок в ука% занных вами местах. Такие рецензии обычно неформальны и про% ходят под управлением автора. Код, таким образом, рассматривает% ся под его углом зрения, со сделанными им допущениями, а не с бо% лее объективной точки зрения стороннего наблюдателя.

Официальные

Задействуя других программистов, вы привлекаете дополнительные знания и опыт и обеспечиваете свежий взгляд на сделанную работу. Широкое рецензирование труднее организовать, но оно может ока% заться более успешным в искоренении проблем. При личной инспек% ции сложно выполнить столь глубокий анализ; автор слишком при% выкает к своему коду и может не обратить внимания на недостатки.

Обычно такое рецензирование производится во время официально% го совещания, но оно может быть и виртуальным, с использованием средств связи.

Рецензирование каждого типа может осуществляться в разные момен% ты разработки. Проверка «один на один» может происходить ежеднев% но, в порядке проверки интеграции перед сохранением модификаций в исходном дереве. Официальное рецензирование вводится ближе к кон% цу разработки в качестве финального аудита качества программного обеспечения.

Помимо очевидных достоинств корректного кода у рецензирования есть другие полезные побочные эффекты. Перекрестное опыление, происходящее при изучении программистами кода своих коллег, спо% собствует единообразию стиля кодирования в проекте. Рецензирование также распространяет знание внутреннего устройства важных участ% ков кода, поэтому уменьшается риск потери информации при уходе программистов из проекта (см. раздел «Роспуск команды» на стр. 439).

Рецензирование кода – отличное средство для поиска и устранения скры& тых ошибок, повышения качества кода, усиления коллективной ответст& венности за код и распространения знаний.

Когда проводить рецензирование?

Если вас не критикуют, значит, вы ничего не делаете.

Дональд Рамсфельд

В идеале каждый кусочек кода должен быть тщательно прорецензи% рован, прежде чем попасть в окончательную версию. Согласно Инсти% туту технологии программирования Университета Карнеги%Меллона, тщательное рецензирование кода должно занимать не менее полови% ны всего времени кодирования (с учетом личного рецензирования)

Создавая систему, выясните, нужно ли проводить рецензирование, и если да, то какого кода.

Нужно ли рецензировать

Мы знаем, что ошибок избежать невозможно и что ваш код наверняка содержит несколько классических ошибок. Очевидные ошибки вы бы% стро обнаружите, но гораздо больше тонких проблем сможет выявить только свежая пара глаз, непредвзято рассматривающих код. Самому автору трудно заметить недостатки, присущие его собственной работе, поскольку он слишком близок к коду и страдает от когнитивного дис# сонанса, как описано у (Weinberg 71). Если ваш код представляет ка% кую%либо ценность (подсказка: да, представляет, иначе вы не стали бы его писать) и вас заботит его качество (подсказка: да, заботит, иначе вы позорите себя), вы должны подвергнуть его рецензированию.

Если вы не рецензируете код, резко возрастает вероятность пропус% тить ошибку в готовый продукт. Это может повлечь за собой неприят% ности, большой объем переделки и обновления продукта с выездом к заказчику, а иногда и финансовый крах вашей компании. Такие по% следствия не сопоставимы с затратами на рецензирование. Согласно Хамфри, «Студенты и инженеры обычно допускают от 1 до 3 ошибок в час при проектировании и от 5 до 8 при написании кода. Они устра% няют лишь от 2 до 4 ошибок в час при тестировании, но обнаруживают от 6 до 12 ошибок в час во время рецензирования» (Humphrey 97).

Для того чтобы не проводить рецензирование, обычно ищут разные оправдания. Например, говорят, что «этот код слишком велик, чтобы полностью рецензировать его» или «он слишком сложен; никто в нем не разберется, и нет даже смысла пытаться его рецензировать». Если проект смог обеспечить достаточное количество человеко%часов, чтобы написать такую программу, найдется и достаточно времени для ее ре% цензирования. А если код слишком сложен, то тем более он нуждается в рецензировании! Возможно, он требует даже более радикальных мер. Грамотно написанный код раскладывается на самостоятельные секции, которые можно рецензировать отдельно.

Какой код рецензировать

В любом проекте быстро образуется масса исходного кода. В любых, кроме самых строгих, процедурах разработки просто нет времени, что% бы рецензировать код до последнего клочка. Как же выбрать те части, которые нужно рецензировать? Это не так просто.

1Более серьезную проблему представляет то, что они редко готовы вообще

тратить время на рецензирование.

Нужно отобрать код, которому рецензирование больше всего пойдет на пользу. Это код, в качестве которого вы больше всего сомневаетесь

Альтернативы рецензированию

Существует ряд технологий разработки, которые, по мнению не% которых, делают излишними официальные рецензии. Перечис% лим их:

Программирование в паре

Программируя в паре (как описано на стр. 409), вы фактиче% ски осуществляете постоянное рецензирование. Две пары глаз лучше, чем одна, и обнаружат гораздо больше ошибок – прямо при вводе. Однако при рецензировании можно обнару% жить еще больше недостатков за счет привлечения к нему лю% дей, которые физически и эмоционально не связаны с данной реализацией.

Open source

Открытое и бесплатное распространение кода позволяет уви% деть его всем желающим, оценить качество и исправить не% достатки. Некоторые считают это вершиной рецензирования. Однако такая система не гарантирует, что кто%нибудь станет изучать ваш код. Только у действительно популярных откры% тых проектов есть активно поддерживаемая кодовая база. Сделав свой код общедоступным, вы не обязательно сразу по% лучите преимущества рецензирования.

Поблочное тестирование

Это средство автоматической проверки того, что модифика% ция не снизила степени корректности вашего кода (см. раздел «Руками не трогать!» на стр. 203). При этом ваш код может представлять собой «спагетти», но если он пройдет поблочное тестирование, никто этого не заметит. Если блочные тесты не% достаточно строги, они могут пропустить ошибки.

Отсутствие рецензирования

Можно просто довериться программисту в расчете, что он все сделает правильно – в конце концов, это его работа. Если та% кой стратегии достаточно для успеха, то и тестировать код ни к чему. В добрый путь!

Ни одна из этих альтернатив в отдельности не может по%настоя% щему заменить рецензирования. Возможно, что их сочетание при наличии в команде какой%нибудь особенно эффективной культуры разработки уменьшает необходимость рецензирова% ния, но мне такие команды еще не встречались.