За время моей работы разработчиком я провел сотни обзоров кода. Это то, чему я научился очень радоваться, так как это дает мне представление других людей о нашей кодовой базе. В большинстве случаев я узнаю из этого что-то новое. В этой статье я хочу дать несколько советов о том, как быть хорошим в них и особенно о том, как наслаждаться ими.
Хороший трубопровод
У большинства команд есть какие-то правила в стиле кода и рекомендации о том, как унифицировать свою кодовую базу. Что бы вы ни делали, не заставляйте проверяющих код проверять, соответствует ли запрос на извлечение этим правилам. Для этого есть инструменты, посмотрите на eslint, SonarQube. Эти инструменты должны быть запущены как часть вашего PR-конвейера.
SonarQube – один из тех инструментов, который улучшит анализ кода для всех членов вашей команды. Он может найти проблемы со стилем, но может сделать гораздо больше. С помощью анализа кода они могут найти наиболее распространенные ошибки, которые вы можете сделать в своем коде. Вы никогда не закрывали свой ресурс? Гидролокатор даст вам знать. Лично я никогда не провожу проверку кода до того, как Сонар закончит свою работу.
Вам нужен конкретный процесс, который будет выполняться каждый раз, когда кто-то создает PR или вносит в него новые изменения. Шаги могут выглядеть примерно так.
- Скомпилируйте код
- Запустите тесты
- Бегать по ворсу
- Запустите SonarQube
- Выполните процесс проверки вручную
- Слияние с основной кодовой базой
Эстакада
Как и в первую очередь, в своем обзоре я сделаю краткий обзор всех измененных файлов. Это я обычно делаю в пользовательском интерфейсе запроса на извлечение. На этом этапе я сосредотачиваюсь на нескольких вещах.
Во-первых, это читаемость кода. Как проходит процесс чтения? Очевидно ли, что делается? Хороший код должен быть способен передать свое предназначение с первого взгляда. Затем я пытаюсь выяснить, соответствует ли это изменение требованиям соответствующего запроса на изменение. Я прочитаю билет и постараюсь соответствовать всем требованиям, изложенным в запросе на получение.
На этом этапе я не углубляюсь в детали реализации. Я определяю их для более поздних стадий.
Возможные моменты, высказанные на этом этапе:
- изменение не очень читабельно
- изменение не распространяется на требования, или заявка на изменение запроса не была изменена по мере изменения требований
- пропущенные тесты
Идите глубоко
После краткого перехода по коду у меня есть список измененных файлов, в которые мне нужно углубиться. Обычно я делаю это в IDE, чтобы лучше видеть соединения между файлами, но для большинства изменений можно сделать это в веб-интерфейсе запроса на извлечение.
Я начинаю с того, что задаю вопрос о том, как бы я решил эту проблему и пошел дальше. Есть ли в нашей кодовой базе фрагмент кода, который делает что-то подобное (или то же самое)? Существует ли библиотека (которую мы используем в настоящее время), которую можно использовать для этого? Если есть библиотека, которую мы в настоящее время не используем, стоит ли ее добавлять для решения этой проблемы?
Обзор тестов
Не забудьте ознакомиться с тестами. Все ли случаи действительны? Есть ли у этих тестов возможность что-то найти? Читабельны ли утверждения? Присутствуют ли вообще тесты?
Не бойтесь сопротивляться, чтобы добавить больше тестов, если вы, как рецензент, чувствуете, что есть возможность добавить их для улучшения кодовой базы.
Будьте милы и воспитывайте
Что бы вы ни делали, не будьте высокомерны, язвительны и не говорите как всезнайка. Если предлагаемое решение действительно, но вы бы сделали это по-другому, вы можете сказать об этом, но также одобрить запрос. Вы можете оставлять образовательные комментарии, но их слишком много может быть вредным. Подумайте о том, что кажется важным. Не спорьте о мелочах, люди разные и имеют разные мнения.
Утверждение
Будьте быстры в одобрении, не идеально – это нормально.
Это золотое правило, которому вы должны следовать.
Для получения дополнительных советов, подобных этому, вы можете следовать за мной на Твиттер .
Оригинал: “https://dev.to/pavel_polivka/how-to-be-good-at-code-reviews-2lpl”