Часть работы каждого разработчика — проверка кода, но хорошо ли вы с ней справляетесь? Я расскажу о том, как сделать хороший обзор кода, и о лучших практиках, которым я научился за годы работы разработчиком. Я также расскажу о том, что должен сделать человек, запрашивающий проверку кода, прежде чем просить об этом.
Мацей Кашубовски уже написал статью о вреде проверки кода, и это немного другая точка зрения. Если вам это интересно, вы можете прочитать это здесь.
Хорошо, без лишних слов, давайте сразу приступим.
Быстрее
Никто не хочет долго ждать обратной связи, а потеря импульса требует энергии, чтобы вернуться к заданному PR. Вот почему проверка кода почти всегда должна быть вашим приоритетом. Я не говорю, что вы должны бросить все, чем занимаетесь в данный момент, чтобы начать проверку кода. Однако, если вы используете Pomodoro или делаете регулярные перерывы, проверьте, есть ли какие-либо PR, и не позволяйте другому человеку ждать вас дольше, чем ожидалось. В идеальном сценарии вы должны сделать обзор в течение часа, чтобы у человека, отправившего заявку, было время поработать над необходимыми исправлениями, не теряя при этом слишком много внимания.
Будьте своим собственным QA
Это может быть немного спорным, но идея состоит в том, чтобы проверить ветку, которую вы просматриваете, и протестировать функции. Это может занять некоторое время, но это гарантирует, что наиболее очевидные ошибки не появятся в промежуточном приложении. Думайте об этом как об инвестиции, которая сэкономит ваше время позже. Позволь мне объяснить. Если вы отправляете приложение с ошибкой, ваш QA тратит время на рассмотрение проблемы, тогда вам нужно тратить время на исправление этой проблемы, и цикл продолжается. Как только я начал это делать, мне стало казаться, что это одна из самых важных частей проверки кода, особенно для фронтенд-приложений.
Обсудить суть
У каждого свой уникальный способ написания кода, и это нормально! Тем не менее, небольшие различия обычно не стоят обсуждения, поэтому вам не следует указывать на них, особенно если вы уже делали их в предыдущих попытках.
Тем не менее, также стоит договориться о некоторых правилах оформления кода. Он должен сократить количество отличий до самых незначительных — туда всегда можно что-то добавить, если вас это раздражает.
Важнейшей передовой практикой для проверки кода является удобочитаемость. Если вы не можете понять фрагмент кода или он занимает слишком много времени, оставьте комментарий или позвоните по телефону, чтобы обсудить его. Иногда помогает даже отладка или просмотр кода в какой-нибудь IDE (если только это не занимает слишком много времени), но не бойтесь выражать свое замешательство, если что-то непонятно.
Автоматизируйте другие
Добавление линтов или других параметров анализа может сэкономить вам много времени. Вам не нужно читать код в поисках этих незначительных проблем, потому что они будут автоматически обнаружены системой, а не человеком. То же самое касается форматирования. Вы можете убедиться, что все файлы отформатированы, установив какой-нибудь гитхук или добавив скрипт на CI — я не могу представить просмотр неформатированного кода.
Дважды проверьте изменения
Это может быть немного спорным, поскольку я согласен с тем, что доверие к своим товарищам по команде является фундаментальным, но это не такое большое недоверие, как вы думаете. Я не имею в виду повторение каждой строки кода. Наоборот, это означает быстрое прохождение кода, чтобы выявить критические изменения или ошибки. И Github упрощает это, когда вы отмечаете файлы как просмотренные.
Что нужно сделать перед отправкой PR
Сделать описание
Предоставьте четкое объяснение того, над чем вы работали в этом PR, так как названиям также может не хватать контекста. Также стоит связать соответствующие документы документации или снять видео или снимок экрана с изменениями.
Проверьте PR самостоятельно, прежде чем просить отзыв
Вы можете найти все мелкие ошибки, опечатки и т. д., поэтому перепроверьте PR, прежде чем просить кого-то еще проверить. Это может быть очень раздражающим, если вы просите кого-то просмотреть сломанный код или что-то, что выглядит не очень хорошо, но вы забыли об этом и продолжили. Если вы не можете внести изменения сейчас, то оставьте комментарий. Это намного лучше, чем вообще ничего не оставить.
Убедитесь, что тесты не проваливаются.
Я говорю не только об автоматических тестах или о самостоятельном запуске приложения. Многие программисты не прилагают таких усилий, потому что думают, что это работа QA. Тем не менее, вы также несете ответственность за предоставление и обеспечение качества ваших изменений. Хорошей практикой является запуск автоматических тестов и статических анализов перед каждой отправкой и форматирование изменений перед их фиксацией. Вы можете быстро добиться этого, используя git hooks. Подробнее о них можно узнать здесь.
Сделайте ваши PR как можно меньше.
В конце концов, на мой взгляд, гораздо проще просмотреть несколько небольших пакетов кода вместо одного огромного, особенно если они не относятся к одному и тому же. Так что делайте ваши толчки как можно меньше. Люди скажут вам спасибо позже.
Краткое содержание
Если вы читали статью Мацея, то видите, что мы согласны и не согласны по некоторым пунктам. Для сравнения, Мачей больше говорит о том, какое влияние проверка кода может оказать на команду. Я полностью сосредоточился на передовых методах проверки кода, не анализируя, вреден он или нет, поэтому, если вы предпочитаете проводить проверки кода, надеюсь, некоторые из этих советов оказались вам полезными.
Первоначально опубликовано на https://appunite.com.
