Способы улучшить свои навыки в качестве автора кода и рецензента
Что такое проверка кода?
Обзор кода — это процесс проверки чужого кода. В рамках процесса человек, добавляющий код, открывает запрос на «вытягивание» или «слияние» на такой платформе, как GitHub или GitLab. Затем владелец кода или другой участник рассмотрит этот запрос. Либо может предложить изменения в коде — для чистоты, стиля и ошибок — либо одобрить код, если он готов к включению в проект.
Зачем заморачиваться с код-ревью?
Важным аспектом проверки кода является контроль качества. Рецензенты могут убедиться, что логика имеет смысл, в код не добавлены непреднамеренные ошибки, он соответствует стилю остальной части проекта и имеет смысл для тех, кто его не писал.
Тем не менее, я бы сказал, что, хотя это и является основной задачей проверки кода, обмен знаниями является еще более важным аспектом процесса. Когда я начал участвовать в проверке кода в качестве участника, я был удивлен, обнаружив, как многому я научился у рецензентов.
Почему я должен следовать вашим шагам?
Как технический руководитель в ElementX, я отвечаю за качество кода, созданного внутри нашей командой и снаружи для наших клиентов.
У меня есть опыт работы как в сфере продуктов, так и в сфере услуг, а также участие в проектах с открытым исходным кодом. Надеюсь, мой GitHub говорит сам за себя с точки зрения моих навыков как участника — с 2 тысячами коммитов в этом году — и как рецензента с 265 отзывами по пулл-реквестам с 5 июня 2022 года (и многими другими до этого).
Хотя моя проверка кода иногда может быть критической (я считаю ее отличным способом обучения), недавно мне было приятно услышать историю о проверке кода от генерального директора ElementX. Услышав шутки от команды инженеров по поводу моих отзывов, он спросил одного из наших разработчиков, что они думают, так как хотел убедиться, что этот процесс полезен для бизнеса. Разработчик заверил его, что шутки были сделаны в шутку. Он был благодарен за то, что проверка кода стала частью нашего процесса, так как видел, как он совершенствуется как разработчик.
Я обнаружил, что следующие шесть шагов помогли мне улучшить мой процесс проверки кода, и я надеюсь, что, добавив некоторые из этих шагов в свой процесс, вы также увидите преимущества.
Шесть шагов
Как участник
- Выберите хорошее название
Вы будете удивлены, насколько важен заголовок пулреквеста. Оно должно быть кратким и понятным, чтобы лучше объяснять ключевые детали изменения.
«В компьютерных науках есть только две сложные вещи: аннулирование кеша и присвоение имен вещам». — Фил Карлтон
Это невероятно важно с точки зрения рецензента, так как большинство проектов squash merge включат ваш код в проект. Это означает, что чаще всего слияние будет использовать заголовок запроса на вытягивание в качестве коммита git, поэтому он должен иметь смысл для конкретного изменения. Чтобы подчеркнуть важность названия, давайте сравним два разных названия (оба являются примерами из моей предыдущей работы):
«Быстрое исправление» или «исправление: разрешить деструктурированным переменным быть змеиным случаем»
Первый пример в истории git ничего не говорит программисту о том, что на самом деле было изменено, однако вы, надеюсь, видите, что второй пример говорит вам о нескольких вещах, таких как а) тип изменения, «исправление» и б) что было исправлено.
Кстати, внимательные наблюдатели заметят, что второй коммит соответствует спецификации обычный коммит. Не все репозитории будут следовать этому соглашению, но я считаю, что это хороший формат, и вы можете легко удалить двоеточие для отличного заголовка.
2. Проверьте свой собственный код
Всякий раз, когда я делаю запрос на вытягивание, я всегда первым просматриваю свой код. Большинство платформ покажут вам сравнение кода, который вы отправляете, с основной веткой git.
Это важная часть процесса, поскольку она дает вам время проверить наличие ошибок и подвергнуть сомнению логику вашего кода, прежде чем сказать: «Да, это готово и на 100% идеально».
Честно говоря, я не мог сосчитать количество просмотренных мной запросов на вытягивание, в которых я вижу, что человек, отправляющий код, не выполнил окончательную проверку своего кода. Это невероятно легко сказать. Обычно это орфографическая ошибка, console.log("HERE");, оставшаяся от отладки, или другие подобные «глупые» ошибки.
Постоянное выполнение этого будет раздражать рецензента кода, поскольку это покажет, что вы не уважаете его время. В конце концов, они автоматически запросят изменения вместе с вопросом «Вы просматривали это?» еще до того, как они начнут свой обзор.
Как рецензент
3. Управление запросами на проверку
Теперь, когда вас повысили до рецензента, вы должны сначала разработать способ управления уведомлениями о запросах на рецензирование.
Если вы этого не сделаете, произойдет одно из двух: а) вы никогда не узнаете о запросе на проверку — это означает, что код потенциально может лежать там месяцами, не улучшая жизнь вашего клиента! или б) когда вы сядете за проверку кода, вы получите 100 уведомлений, информирующих вас о том, что ваша проверка была запрошена для 100 различных проектов!
Существуют отличные инструменты, которые помогут вам справиться с этим. Swarmia или GitHub Notifications — это только два из них, которые могут помочь вам справиться с этим. Кроме того, вы можете использовать электронную почту и фильтры, чтобы сделать это за вас. Вам нужно найти то, что работает лучше всего для вас. Самое главное — получить доступ к запросам на проверку, просмотреть код и разблокировать свою команду.
4. Задавайте себе вопросы
- Имеет ли смысл это имя переменной?
- Эта функция находится в правильной папке?
- Он живет в правильном файле?
- Имя файла правильное?
Как рецензент, вы должны задать себе все эти вопросы, когда просматриваете код другого человека.
Скорее всего, если это не имеет смысла для вас, это не будет иметь смысла ни для кого другого. Это более важный шаг для владельцев кода, потому что, если вы не можете понять код, который кто-то предлагает для вашей кодовой базы, высока вероятность того, что код будет труднее поддерживать и содержать ошибки или лазейки в системе безопасности.
5. Не торопитесь
Когда я начинал просматривать код, я бесцельно прокручивал страницу вверх и вниз, не пытаясь понять, что происходит. Неизбежно, я бы просто одобрил запрос на включение. К счастью для меня, мне удалось понаблюдать за некоторыми замечательными программистами, и от них я узнал маленький секрет, применимый ко всему в жизни:
Медленно плавно, плавно быстро.
В мире, где ожидается, что все будет происходить мгновенно и быстро, замедлению необходимо придавать большее значение, чем когда-либо. При просмотре кода это не должно быть исключением. Не торопись; понять каждую строчку.
6. Не бойтесь задавать вопросы
Как и в случае с медленной работой, если вы не понимаете строку кода, не бойтесь спрашивать об этом участника. Если они не могут дать вам удовлетворительного ответа, скорее всего, логика слишком сложна, или они не понимают, что делают.
Я знаю, что для некоторых людей это сложно, но отклонение запроса на извлечение из вышеперечисленного допустимо. Вы часто обнаружите, что люди будут больше уважать вас за то, что вы задаете вопросы, придерживаетесь своей позиции и говорите «нет» вещам, которые не имеют смысла. Ваше будущее «я» также поблагодарит вас за это, когда вам нужно будет исправить ошибку в коде, который вы ранее просмотрели и поняли.
Как
Итак, Дэниел, как я могу принять участие в код-ревью? Один из самых простых способов принять участие — просмотреть некоторые зависимости, которые вы использовали в своем собственном коде, перейти в их репозиторий на GitHub и посмотреть, есть ли какие-либо help-wanted проблемы, с которыми вы могли бы помочь. .
В качестве альтернативы, если на вашем рабочем месте проводится проверка кода, принимайте более активное участие. Попросите включить вас в качестве рецензента кода. Вы можете объяснить автору кода, что хотите улучшить свои навыки, учить и учиться у них.
Если на вашем рабочем месте не проводят проверки кода — спросите их, почему они этого не делают. Затем укажите своим коллегам на эту статью, чтобы узнать о преимуществах и о том, как они могут улучшить свое программирование.
