рецензирование, проводимое при включении нового кода в основную ветку разработки.

Его можно проводить:

•Перед записью нового фрагмента кода в систему контроля версий.

•Сразу после записи нового фрагмента кода в систему контроля версий.

•После слияния ветви разработки функции с главной ветвью.

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

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

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

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

Пересмотрите свое отношение

Как хотите, чтобы с вами поступали люди, так поступайте и вы с ними.

Лука 6:31

Рецензирование требует конструктивного подхода; без правильного от% ношения пользы не будет. Это касается обеих сторон – и автора, и ре% цензента.

1Сравните с модератором проекта open source, который сравнивает патчи, поступившие от разных разработчиков, и включает их в основное дерево

кода, периодически выпуская обновленные версии.

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

Кем бы ни был написан код, он подлежит рецензированию и тщательному изучению со стороны коллег. Добивайтесь рецензирования своего кода.

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

Это неэгоистичное программирование, описанное Джеральдом Вайн% бергом в книге 1971 года «The Psychology of Computer Programming» (Психология компьютерного программирования): не устаревающее опи% сание критического отношения, благодаря которому рецензии оказы% ваются действенными. (Weinberg 71) Те программисты, которые не бо% ятся, что кто%то другой найдет в их коде ошибки, пишут в результате более надежные и правильные программы. Стремление к тому, чтобы вам помогли найти ошибки в вашей работе, существенно характеризу% ет программиста%мастера.

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

Позиция рецензента

При рецензировании кода и его критике нужно проявлять деликат% ность. Комментарии должны быть конструктивными, а не преследую% щими обвинительные цели. Не нападайте на автора лично. Важно про% являть дипломатичность и такт. Адресуйте свои комментарии коду, а не его автору. Лучше сказать: «Код всегда…», а не «Вы всегда…».

Рецензирование кода – это процедура с равными участниками: стар% шинство здесь не имеет значения, и учитываются все точки зрения. Любопытно, что даже наименее опытному программисту найдется что сказать в рецензии на код. При этом рецензирование может пойти на пользу как автору, так и рецензенту.

Система в безумии

Рецензирование кода – повсеместно признанная технология, бы% тующая со времен перфокарт. Мы подробно рассмотрели две процедуры, но существует много тонких разновидностей рецен% зирования. Команды программистов выбирают тот механизм, который более подходит их членам и характеру работы. (Жаль те команды, которые вообще не проводят рецензирования.)

Вот еще два популярных метода рецензирования:

Проверки Фэгана

Это достойная процедура формального рецензирования, во многом совпадающая с описанной в данной главе и предло% женная Майклом Фэганом в его книге «Defect Free Process» (Процесс устранения дефектов) (Fagan 76). Фэган подчерки% вает важность умения осуществлять рецензирование и пока% зывает, как можно его развить. Инспекции Фэгана выявляют проблемы как в продукте, так и в технологии его создания.

Дублирование

Это промежуточная точка между парным программировани% ем и рецензированием кода. У каждого модуля есть главный разработчик, работающий над кодом. Назначается также дублер (shadow developer), периодически обсуждающий мо% дуль с главным разработчиком. По ходу кристаллизации про% екта дублер проверяет принятые решения. По ходу написа% ния кода дублер контролирует достигнутые результаты и да% ет конструктивные советы.

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

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

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