Должен также отметить, что я не по всем пунктам согласен с автором (в конце он уже начинает зарываться) и, разумеется, обзоры кода — это не серебряная пуля, но, тем не менее, очень и очень полезная практика.)
Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.
Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.
Причина №2. Находит больше ошибок, чем при применении одного тестирования.
Это очевидно: тестирование находит ошибки. Обзор кода находит другие ошибки. Примененные вместе, они находят больше ошибок, чем можно было бы найти перед отправкой продукта клиентам.
Причина №3. У миллиона обезьян иногда получается валидный синтаксис, даже если он ничего не означает. Компиляторы не могут это отследить.
Иногда вы совершаете синтаксическую ошибку, состоящую из валидного кода, так что компилятор не может ее отследить. Классическая подобная ошибка в C — это = (присвоение) и == (оператор булевого равенства); в этом случае большинство компиляторов могут выдать предупреждение, но есть также и другие примеры. Обзор кода быстро выявит такую ошибку, тогда как найти ее с помощью тестирования может быть достаточно тяжело.
Причина №4. Найди и уничтожь ошибки там, где они живут, вместо поиска гнезда по их
Когда вы получаете отчеты об ошибках из обзора кода, у вас уже есть на руках точный номер строки и описание проблемы. Когда вы получаете отчеты от системного тестирования или (о, ужас!) от пользователя, у вас есть — в лучшем случае — набор шагов для воспроизведения ошибки. Затем только от вас зависит, сможете ли вы найти саму ошибку в коде, что занимает обычно довольно много времени, особенно, если код был написан неделями или месяцами ранее. (см. причину №1.)
Причина №5. Обучайте нубов.
Обзоры кода — это эффективный обучающий инструмент. Сначала, новички-программисты, участвующие в обзорах кода, получают доступ к коду других программистов и, таким образом, могут «прочувствовать» стандарт кодирования и стиль документации. Далее, неопытные программисты получат оценку их кода перед тем, как у них будет шанс заразить систему своим низкопробным кодом. (Потому что мы все знаем, что код, который мы писали 10 лет назад, возможно, ужасен — только если ему не посчастливилось пройти обзор у более старших разработчиков. Если вы программируете менее нескольких лет, помните, что все, что вы пишите сегодня, возможно, ужасно, но вы не сможете этого оценить еще в течение нескольких лет; см. причину №6.)
Причина №6. С самого начала используется эго разработчика для форсирования качества кода.
Теория здесь такая: зная, что код будет публично и внимательно исследован группой коллег, разработчики будут работать более тщательно, чтобы избежать стыда при нахождении всевозможных ошибок в их коде.
Комментарий от гостя @kyletolle: Причина №7. Разъяснение кода гарантирует его понимание. Убираются пометки типа «Нуу, я всегда это так делал...».
После того, как вам придется ответить несколько раз на один и тот же вопрос во время обзора, возможно, вы зададитесь вопросом и во время кодирования. (см. причину №6.)
Причина №8. Ускоряет тестирование. Черт, да всю разработку ускоряет!
Есть несколько основных причин для этого. Во-первых, так как обзор кода обнаруживает и исправляет дефекты прямо на его месте (см. причину №4), соответственно, тратится меньше времени на его исправление. Во-вторых, тестеры находят меньше ошибок, поэтому они проводят меньше времени над составлением вопросов, над которыми потом корячится отдел разработки. В-третьих, тестерам не надо перезапускать регрессионные тесты так много раз, потому что будет меньше релиз-кандидатов продукта… Ну и в-последних, тестеры будут меньше простаивать, ожидая исправлений ошибок.
Причина №9. Чем меньше количество рассерженных пользователей, тем счастливее ваша служба тех. поддержки..
Доказательство: Меньшее количество багов в продукте (см. причину №2). Т.к. баги не так часто досаждают пользователям, то последние реже становятся злыми. Поэтому когда пользователи наконец позвонят, они будут воспевать вам хвалу. (Ладно, возможно та часть про песни не совсем правда, но, думаю, общий смысл вы уловили.) Доказательство с другой стороны: если вы тратите меньше времени на исправление багов, вы можете тратить больше времени на разработку новых возможностей, о которых так просят ваши пользователи.
Причина №10. (Анти-причина) Придется платить больше комиссионных из-за большего количества продаж… эй, это ж здорово!
Когда пользователи поют хвалу стабильности вашему продукту, его легче продать как новым пользователям так и увеличить объемы продаж уже существующим. Конечно, комиссионные продажникам пойдут вверх, но я еще ни разу не слышал, чтобы кто-то об этом жаловался слишком уж громко.
Причина №11. Есть инструменты, уменьшающие раздражающий фактор «классических» процессов обзора.
(прим. перев. Список инструментов был позже приведен в этой совсем короткой статье, я решил вставить его прямо в это правило, дабы собрать всю информацию в одном месте).
Вот список инструментов обзора, без какого-либо определенного порядка. Я не пробовал их все, так что они даны без сравнения. Если вы знаете еще какие-либо инструменты, оставляйте комментарии и я дополню список.
Codestriker — Открытое (опенсорс) веб-решение, кажется, написанное на Perl.
Code Collaborator — Платный продукт.
Review Board — Открытое (опенсорс) веб-решение, кажется, написанное на python/Django.
Rietveld — Открытое(опенсорс) решение от Google. Попытка №2 Гвидо ван Россума по инструментам обзора. Отгадайте с 3-х раз, на чем оно написано…
Crucible — Платный продукт от компании Atlassian.
Итог: не пытайтесь делать это вручную, вы потратите кучу времени пересылая патчи и отслеживая дефекты, в то время как инструменты могут автомагически это сделать за вас.
Причина №12. Риск нулевой. Даже не-такие-уж-супер-эффективные обзоры бьют тестирование.
Если бы я потратил немного времени, то мог бы откопать несколько опубликованных исследований для обоснования этой причины. Но по моему личному опыту, обзоры кода примерно в 4 раза эффективнее чем юнит-тесты. Поэтому, даже если я провожу обзор без особого энтузиазма, я все еще более эффективен, чем тестирование. (См. причины №2 и №4, также помните про причину №5, которая не дает мгновенно измеримый эффект.) Также скорее всего должны быть и данные, говорящие что обзоры кода — это трата времени. Также возможно и некоторое количество летающих оленей. (прим. перев. Стив Макконнелл в своей книге «Совершенный код» действительно приводит довольно много результатов исследований, подтверждающих эффективность обзоров кода перед тестированием, а также говорит о том, что при применение обеих этих техник дает результат гораздо лучший, чем использование какой-либо одной из них.)
Причина №13. (Анти-причина) Тестеры будут скучать, из-за того что не смогут найти много ошибок… Ах, да! Они смогут сосредоточиться на стресс/нагрузочном тестировании. Хотел бы я иметь такую проблему…
Причина №14. Проведение обзоров — это хорошая практика для проведения обзоров. Вы становитесь лучше.
Эффективность проведения обзоров в вашей команде будет улучшаться со временем. Это означает что долгосрочный риск ошибок даже меньше, чем краткосрочный (см. причину №12 почему риск ошибки равен или очень близок к нулю).
Причина №15. Это отличный способ составить действительно полезный контрольный список для проведения обзоров.
Ну, это немного сомнительно, контрольный список для проведения обзоров вообще-то мало волнует пользователя (Мне, наверное, стоило придумать еще пару причин для объяснения «искусственных заполнителей»… Эй, я твитил это во время напряга в 3 часа дня перед полдником!)
Причина №16. Гипотетически: меньшая текучка кадров из-за того, что разработчики проводят меньше времени исправляя раздражающие ошибки.
Не знаю как другие, но я остался на работе, которая в других отношениях была не такой уж классной, из-за качества команды, в которой я работал и окружающих меня людей. Здорово ощущать себя частью хорошо смазанной машины. Это мотивирует приходить на работу каждый день, зная, что ты произведешь высококачественный продукт и твои коллеги будут рядом, чтобы прикрыть тебя.
Причина №17. Уменьшается риск выбиться из графика, потому что качество продукта растет с каждой завершенной фазой проекта.
Ваши тестеры не будут простаивать (см. причину №8) и тестирование не затянется. Т.к. вы получите ответную реакцию достаточно быстро относительно графика (см. причину №1), вам легко удастся определить сколько времени займет тестирование.
Причина №18. Ответная реакция (особенно от коллег) на уровне исходного кода означает, что вы прекратите совершать одни и те же ошибки снова и снова (см. причину №6).
Это исходит из того факта, что каждый разработчик будет иметь на руках данные о типах ошибок, которые он совершает и, таким образом, сможет найти способы для предотвращения этих ошибок. И вот где действительно начинается магия: когда вы начинаете думать о предотвращении целого класса ошибок.
Причина №19. Улучшение качества документации / комментариев, как и самого кода.
(См. причину №7) Разработчики будут лучше комментировать код, чтобы избежать ответов на большее количество вопросов от аудиторов. Если аудиторы ищут несоответствия между комментариями и кодом, это дополнительная мотивация к тому, чтобы поддерживать документацию в обновленном состоянии. В конечном счете, я подозреваю что чересчур замудренный код станет дефицитом, т.к. будет изучен и опрошен больше раз, чем обычный код.
Причина №20. Пользователи найдут не так много жуков в своем супе.
Эта причина может показаться ненужной в связи с причиной №9, но помощь пользователям это ведь смысл нашей работы, так ведь? Поэтому пусть она остается и — как я говорил выше — я поработаю над еще парочкой причин для добавления в список.
P.S. Перенёс в блог «Ревизия кода».
комментарии (26)