Главное Авторские колонки Вакансии Образование
Выбор редакции:
😼
Выбор
редакции
379 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

​Качественное ревью кода

Все знают, что ревью кода важно, но почему? Оно помогает найти баги и предотвратить их попадание в продакшн, но разве это единственная функция? А вот и нет. В новой статье рассказываем про 3 цели ревью кода и как его делать еще лучше.
Мнение автора может не совпадать с мнением редакции

Почему мы делаем ревью кода?

Все знают, что ревью кода важно, но почему? Оно помогает найти баги и предотвратить их попадание в продакшн, но разве это единственная функция?

3 цели ревью кода:

  1. Следить за изменением кодовой базы.
  2. Улучшение качества проекта.
  3. Предоставление обратной связи разработчикам.

Следить за изменением кодовой базы

В первую очередь поймите, зачем вы это делаете

Чтобы понять изменение кода, сначала нужно понять, почему оно было сделано.

Большинство из нас работает с какой-то системой трекинга. Определите тикет, связанный с изменением кода, и внимательно прочтите его, включая комментарии. Прочитайте описание в пул-реквесте, если таковое имеется. Это даст вам контекст, необходимый не только для понимания самих изменений, но и для оценки того, соответствуют ли изменения требованиям.

Если нет задач/тикетов и PR-описания, запишите собственное описание и включите его в ревью.

Читайте, а не пробегайте глазами

Не довольствуйтесь фразой «выглядит хорошо». Весь качественно отформатированный код выглядит хорошо. Вам нужно прочитать изменения и действительно понять их. Да, это сложно. Да, это займет больше времени. Но это того стоит. Это повышает шансы обнаружить не столь очевидные баги.

Улучшение качества проекта

Одна голова хорошо, а две еще лучше. Это как раз про ревью кода.

Всегда запускайте код

Изменил одну строчку? Запусти код. Простые CSS изменения? Запусти код.

Не обманывайте себя, думая, что все всегда собирают и запускают проект после каждого изменения, которое вносят. Мы должны ... но не делаем.

Если были внесены какие-либо видимые пользователю изменения, убедитесь, что вы видите их своими глазами. Нажмите на новые компоненты пользовательского интерфейса.

Запустите тесты. Да, я знаю, что QA это сделает. Но не ленитесь проверять самостоятельно, иначе потом потратите больше времени на то, чтобы переделать.

Включают ли изменения миграцию базы данных? Завершите процесс проверки, откатив их назад, проверив мастер и проверив, работает ли еще проект.

Не придирайтесь

Не тратьте время и терпение на тривиальные проблемы. Лишняя пустая строка - это еще не конец света. Вместо этого попробуйте найти решение, которое обеспечит автоматическое обнаружение всех этих тривиальных деталей и предложите его использовать команде.

Сосредоточьтесь на читабельности кода

Автоматизированные инструменты для проверки длины имени функции и правильного отступа, позволяют сосредоточиться на важных вещах, которые заметит только человек.

Эти имена функций/переменных имеют смысл? Используют ли они словарный запас проекта последовательно? Могут ли они сбить с толку? Есть ли двусмысленные сокращения?

Предоставление обратной связи разработчикам

Всегда говорите что-то хорошее.

Отзыв должен быть конкретным и не содержать негативных формулировок.

Если вы боитесь показаться глупым за то, что цените тривиальные вещи, спросите себя, что вы чувствуете, когда кто-то проверяет ваш код. Волнение? Страх? Кто-то из вашей команды испытывает то же самое. Подбодрите человека добрым словом, даже если дела плохи. Это сделает его более открытым и настроенным на качественное исправление.

Избегайте осуждающего и властного тона

Самый простой способ перестать звучать осуждающе и властно - предположить, что вы не правы, а рецензент прав. Затем задайте вопросы, которые помогут вам понять, почему вы не правы. В конце концов, они, вероятно, потратили гораздо больше времени на работу над этим кодом, чем вы потратили на его проверку.

Не говорите «не делай так, а делай вот так, я знаю лучше». Вам нужно, чтобы команда думала творчески и критически, а не выполняла приказы.

Вместо этого говорите «а как ты думаешь ...». Это показывает, что вы цените человека и его работу.

Краткое резюме:

Следите за изменениями кодовой базы

  • В первую очередь поймите, зачем вы это делаете
  • Читайте, а не пробегайте глазами

Улучшение качества проекта

  • Всегда запускайте код
  • Не придирайтесь
  • Сосредоточьтесь на читабельности кода

Предоставление обратной связи разработчикам

  • Всегда говорите что-нибудь хорошее
  • Избегайте осуждающего и властного тона

Перевод How to give great code reviews от Digital Skynet

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.