Перевод статьи «Code Reviews Are Awesome, Here Are 7 Reasons Why».
Ревью кода это отличная практика, которую стоит применять в разработке программ. Суть ее очень проста: написав код, дайте его кому-нибудь другому, чтобы он просмотрел и прокомментировал.
Несмотря на простоту, ревью кода приносит заметные дивиденды. Вот 7 причин, по которым данная практика очень полезна.
1. Выявление багов
Другой разработчик может найти в вашем коде баги или забытые сценарии, лишь взглянув на него.
Никто не пишет совершенный код постоянно. Поэтому «одна голова – хорошо, а две – еще лучше».
Даже QA-инженеры могут упустить какие-то неочевидные вещи, которые, тем не менее, с легкостью увидит другой человек со «свежим» взглядом.
2. Выявление проблем
Вы можете не заметить что-то, что можно улучшить, хотя оно не является багом в строгом смысле слова. Подумайте над такими вопросами:
- «Это не то чтобы баг, но, возможно, лучше бы мы вместо этого сделали Х, как полагаешь?»
- «Если элементов слишком много, этот метод будет медленным. Как насчет того чтобы сначала рассортировать элементы и использовать бинарный поиск? А если использовать hashmap / кучу / график / набор / умный алгоритм / индекс в этом поле / сбор мусора?»
- «Возможно, нам стоит нормализовать эти таблицы и не дублировать эти данные?» (А может, как раз наоборот).
- «Пропущены тесты для ситуации N».
- «Когда пользователь делает Х, система идет по пути Y. Но что если пользователь предпочтет Z?»
3. Улучшение качества
Возможно, вы используете инструмент статического анализа, такой как StyleCop для C#, Checkstyle для Java или Lint для CSS. Однако, подобные инструменты не могут распознать все проблемы.
А вот человек, выполняющий ревью вашего кода, может дать совет относительно имени класса или того, как разбить логику между методами, или как разделить ответственность между модулями или сервисами.
Кроме того, это отличная проверка читаемости кода. Коллега, выполняющий ревью, должен суметь прочесть ваш код с легкостью. Это важно, ведь мы читаем код в 10 раз чаще, чем пишем его.
Разработчик, пишущий код, настолько погружен в контекст, что ему все в этом коде понятно. Но спустя пару месяцев эти знания испаряются, и ваш собственный код уже выглядит настолько незнакомым, будто его писал кто-то другой. Поэтому в ваших собственных интересах сделать его хорошо читаемым.
А может ли быть для этого лучший способ, чем дать его почитать кому-нибудь еще?
4. Тестирование
Человек, выполняющий ревью, запускает ваш код, чтобы посмотреть, работает ли он вообще, и как именно он работает. Таким образом он может найти какие-то баги. И это прекрасно, поскольку помогает вам опубликовать лучший продукт, быстрее получить обратную связь и при этом снизить нагрузку на QA.
5. Обучение джуниоров
Было бы ошибкой считать, будто джуниоры не могут или не должны делать ревью кода старших разработчиков. Они очень даже способны находить баги или проблемы с читаемостью кода.
Но важно еще и то, что таким образом они учатся работать. Когда вы даете им на ревью хороший код, вы учите их на примере.
6. Распространение знаний
Член команды, просматривая чей-то код, узнает о части системы, в которую вносятся изменения. Это помогает лучше понять систему в целом.
В следующий раз, когда он будет реализовывать функционал в этой области, он будет к этому готов.
7. Установление доверительных отношений
Я знаю, это звучит немного странно. Как я могу доверять коллегам, которые меня критикуют?
Но подумайте вот о чем. Когда ревью кода выполняется каждым членом команды на равных, это помогает всем почувствовать доверие к себе. Это создает ощущение взаимодействия. Если вас просят сделать ревью кода, вы чувствуете, что коллега уважает и вас, и ваше мнение. Когда вы просите кого-то сделать ревью вашего кода, вы показываете, что цените вклад этого человека и что вы открыты для обратной связи и улучшения.
Нужно следить за тем, чтобы критика была конструктивной, а человек не чувствовал, что на него нападают или хотят унизить. Если кто-то вам говорит, что ваш код ужасен, это точно не поможет установлению доверительных отношений. Это демотивирует и попросту раздражает. Вы больше не захотите обратиться к этому человеку.
Обратная связь должна подаваться доброжелательно и конструктивно, с обязательным (!) пояснением причин. Непременно нужно объяснять, почему вы считаете, что что-то должно быть сделано иначе. Вы нашли баг? Обнаружили проблему? Код плохо читается? Он не сочетается с другими частями вашей системы? Скажите об этом.
Лучше всего будет, если вы дадите конструктивный совет насчет того, как сделать код лучше.
А вы делаете ревью кода в вашей команде? Как выглядит этот процесс? Поделитесь в комментариях!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]