Чтобы быть отличным программистом, требуется не только писать чистый код. Помимо этого, нужно уметь читать и понимать чужой код, а также давать ценные рекомендации по его улучшению.
Способность проводить полезные обзоры кода, получая обратную связь от коллег, выделит вас среди других инженеров. Поговорим о том, что нужно и что нельзя делать при обзоре кода, чтобы от него была польза.
1. Нужно: задавать уточняющие вопросы
От вас не требуется знать все. Понять код может быть довольно сложно, особенно если вы впервые работаете с этой базой кода или не знаете контекста. Не бойтесь задавать вопросы, если что-то непонятно.
Обзор кода создается общими силами. Рецензент и написавший код разработчик находятся в одинаковом положении, давая друг другу шанс учиться и расти.
Кроме того, пренебрегая возможностью выяснять непонятные моменты при обзоре кода, вы неизбежно столкнетесь с ними позже, когда будете иметь дело с тем же блоком кода.
Нельзя: принимать замечания близко к сердцу
Комментируя код, человек не нападает на его создателя. Если другой разработчик предлагает альтернативный способ выполнения, он просто хочет повысить качество кода. Он вовсе не считает, что вы не знаете, как писать код, или что ваш код плох.
Не будьте тем, кто проявляет пассивную агрессию по отношению к коллеге, проверяющему работу. Это заставляет людей чувствовать себя некомфортно и отбивает желание пересматривать код, что в конечном итоге вредит всей команде. Относитесь с пониманием к предложениям коллег и улучшениям, которые они советуют внести.
2. Нужно: использовать псевдокод при комментировании пул-реквестов
В некоторых ситуациях полезно написать предложение по улучшению кода простым и понятным языком. Но иногда короткий блок псевдокода может внести больше ясности, чем комментарий.
Псевдокод часто позволяет донести идею до разработчика, который будет его проверять. Рассмотрим этот момент на примере.
Код:
const someData = ["hi", "test", "blah", "hello"] const array1 = someData.filter((val) => val[0] === "h"); const array2 = someData.filter((val) => val[0] === "t"); const array3 = someData.filter((val) => val[0] === "b");
Предложение, внесенное в процессе его обзора:
Я понял, что вы пытаетесь отфильтровать данные в исходном массиве в 3 отдельных массива в зависимости от первой буквы слова. Вместо того чтобы создавать 3 отдельных фильтра, как насчет этого…
create empty arrays [] for array1,2,3for( i = 0; i < someData.length ; i++) { if(someData[i][0] === "h") array1.push(someData[i]); if(someData[i][0] === "t") array1.push(someData[i]); if(someData[i][0] === "b") array1.push(someData[i]);}
Таким образом, вам не придется проходить someData 3 раза с тремя различными функциями фильтрации. Вместо этого, вы пройдете его один раз в одном цикле for, проверяя каждый элемент по мере выполнения!
Обратите внимание, что в замечании указана предположительная цель блока кода, а затем предложен альтернативный подход для достижения того же результата.
Псевдокод обеспечивает техническую ясность предлагаемого решения. Так не приходится подробно его расписывать и надеяться, что другой разработчик его поймет.
Нельзя: принимать пул-реквесты, не прочитав и не поняв код
Это вредно во всех отношениях. Вот только некоторые из последствий:
- риск попадания некачественного кода в базу;
- повышение вероятности появления ошибок в программе;
- отсутствие возможности обучения обеих сторон процесса — рецензента и разработчика, представившего код на рецензию;
- развитие вредных привычек в командах.
Список можно продолжить, поэтому не ленитесь читать код своих коллег.
3. Нужно: хвалить автора
Обзор кода — совместный процесс. И это не всегда сплошная критика. Иногда, просматривая чужой код, можно узнать новый способ выполнить какое-либо действие, новую функцию, новый подход к написанию алгоритма и т. д.
Не стесняйтесь оставлять добрые комментарии, отмечая в них все, что оказало на вас положительное влияние. Часто это может привести к продуктивному общению, выходящему за рамки проверяемого кода.
Кроме того, показывая коллегам, что читаете их код и учитесь у них, вы тем самым поднимаете моральный дух команды. Всем нравится, когда признают их достоинства, так что не стесняйтесь оставлять в комментариях комплименты автору!
Нельзя: объединять несвязанные изменения в одно ревью
Важно подавать изменения удобными для восприятия фрагментами. Не стоит отправлять рецензенту обзор кода с пересмотром множества различных функций и ошибок.
Если рецензент не понимает конечной цели того, что нужно проверить, это усложняет процесс обзора. Когда вы пишете большую функцию, то не останавливаетесь и не исправляете другие ошибки, пока не закончите ее. Так легче сосредоточиться на конечной цели. То же самое можно сказать и о рецензентах.
Составить общую картину будет сложнее, если в одном наборе изменений файла вы исправляете ошибку, а в другом — рефакторите алгоритм, чтобы сделать его более читабельным.
Заключение
Обзоры кода дают команде множество преимуществ. Это и замечательная возможность учиться у коллег, и отличный способ командного взаимодействия, и эффективный инструмент повышения качества кода.
Ежедневно уделяя несколько минут обзорам кода, вы не только повысите ценность того, что предлагаете своей команде, но и обеспечите себе быстрый профессиональный рост.
Читайте также:
- Как обнаружить дублирование кода в проекте
- 5 советов о том, как улучшить комментарии в коде
- Сделайте свой первый вклад в открытый исходный код!
Читайте нас в Telegram, VK и Дзен
Перевод статьи Adriano Triana: Effective Do’s and Don’ts for Your Next Code Review
