За время работы в качестве разработчика я провел сотни обзоров кода. Это то, что мне очень нравится, так как это дает мне возможность взглянуть на нашу кодовую базу с точки зрения других. Чаще всего я узнаю из этого что-то новое. В этой статье я хочу дать несколько советов о том, как добиться в них хороших результатов и особенно о том, как получать от них удовольствие.
Хороший трубопровод
У большинства команд есть какие-то правила стиля кода и рекомендации по унификации своей кодовой базы. Что бы вы ни делали, не заставляйте рецензентов кода проверять, соответствует ли запрос на вытягивание этим правилам. Для этого есть инструменты, например eslint, SonarQube. Эти инструменты должны использоваться как часть вашего PR-конвейера.
SonarQube - один из тех инструментов, которые улучшат проверку кода для всех в вашей команде. Он может найти проблемы со стилем, но может сделать гораздо больше. С помощью своего анализа кода они могут найти наиболее распространенные ошибки, которые вы можете сделать в своем коде. Вы никогда не закрывали свой ресурс? Сонар сообщит вам об этом. Лично я никогда не занимаюсь проверкой кода до того, как Sonar завершит свою работу.
У вас должен быть конкретный процесс, который будет запускаться каждый раз, когда кто-то создает PR или вносит в него новые изменения. Шаги могут выглядеть примерно так.
- Скомпилируйте код
- Запустите тесты
- Выполнить линтинг
- Запустите SonarQube
- Выполните процесс проверки вручную
- Слияние с основной кодовой базой
Эстакада
Как и во-первых, в своем обзоре я сделаю краткий обзор всех измененных файлов. Обычно я делаю это в пользовательском интерфейсе запроса на вытягивание. На этом этапе я сосредотачиваюсь на нескольких вещах.
Во-первых, читаемость кода. Как опыт чтения? Очевидно, что делается? Хороший код должен с первого взгляда отражать его цель. Затем я пытаюсь выяснить, требуется ли это изменение для соответствующего запроса на изменение. Я прочту тикет и постараюсь учесть все требования, указанные в запросе на перенос.
На этом этапе я не углубляюсь в детали реализации. Я определяю их на более поздних этапах.
Возможные моменты, озвученные на этом этапе:
- изменение не очень читаемо
- изменение не покрывает требования, или тикет запроса на изменение не был изменен, так как требования изменились
- пропущенные тесты
Сделать глубокий
После краткого обзора кода у меня есть список измененных файлов, в которые мне нужно углубиться. Обычно я делаю это в среде IDE, чтобы лучше видеть связи между файлами, но для большинства изменений можно сделать это в веб-интерфейсе запроса на перенос.
Я начинаю с того, что задаю вопрос, как мне решить проблему, и двигаться дальше. Есть ли в нашей кодовой базе фрагмент кода, который делает что-то похожее (или то же самое)? Есть ли библиотека (которую мы сейчас используем), которую можно использовать для этого? Если есть библиотека, которую мы не используем в настоящее время, стоит ли ее добавлять для решения этой проблемы?
Обзор теста
Не забудьте просмотреть тесты. Все случаи действительны? Есть ли у этих тестов возможность что-то найти? Можно ли читать утверждения? Есть ли вообще тесты?
Не бойтесь дать отпор, чтобы добавить больше тестов, если вы, как рецензент, чувствуете, что есть возможность добавить их для улучшения кодовой базы.
Будьте милы и обучайте
Что бы вы ни делали, не будьте высокомерны, язвительны и не говорите как всезнайка. Если предложенное решение действительно, но вы бы поступили иначе, вы можете сказать об этом, но также утвердите запрос. Вы можете оставлять образовательные комментарии, но их слишком много может быть вредным. Подумайте, что кажется важным. Не спорьте по мелочам, люди разные и имеют разные мнения.
Одобрение
Быть быстрым на одобрение, несовершенное - это нормально.
Это золотое правило, которому вы должны следовать.
Чтобы получить больше подобных советов, вы можете подписаться на меня в Twitter.
Первоначально опубликовано на https://dev.to 5 мая 2021 г.
