Ревью кода — связующее звено во взаимодействии любой эффективной команды разработчиков ПО. На этом этапе инженеры делают запрос на слияние изменений с главной веткой разработки. Другие участники группы, а также старшие руководители, в праве прокомментировать и внести коррективы в код посредством систем контроля версий Git и GitLab.
Ревью кода знаменует собой поворотный момент, при котором изменения, выполненные отдельным инженером, становятся частью общего вклада всей команды в центральную базу кода.
Этот переход является наиважнейшим этапом ревью. Первоначально кодом владеют один-два разработчика, а в завершении он становится уже общей собственностью. Как только произошло слияние, все потенциальные ошибки и недочеты становятся проблемой не просто авторов кода, а всех непосредственных участников.
В эпоху преимущественно удаленной работы технологических команд ревью приобретает особое значение. Отдельное внимание необходимо уделять планированию требуемого времени на проверку кода коллег. При условии эффективно отлаженного процесса ревью команде удается придерживаться стандартов индустрии, быстрее проводить адаптацию новых специалистов, а также создавать надежное ПО. И это только небольшой перечень преимуществ.
С учетом всего вышесказанного мастерское владение навыками ревью кода способствует общему профессиональному развитию. Если вы слишком часто жмете на кнопку “Approve” (“Одобрить”), то самое узнать эти 5 правил, которыми должен руководствоваться каждый рецензент кода.
1. Всегда делитесь своими мыслями
Как бы очевидно это ни звучало, участие в ревью требует критического отношения к собственным размышлениям. Если вы новичок в этом деле или не понимаете внутренней работы кода, стоит озвучивать неясные для вас моменты. При необходимости обращайтесь за помощью к коллегам через мессенджер перед тем, как прокомментировать запрос на слияние.
Даже старшие разработчики периодически обращаются за разъяснениями. Решением может оказаться как простое добавление комментария для операций над байтами, так и полный рефакторинг алгоритма. Главное, чтобы всем участникам команды все было понятно.
Только представьте, что старшие разработчики компании решили утаить тот факт, что не разобрались в коде запроса на слияние. Жуть! Вот почему так важно, особенно для начинающих специалистов, озвучивать свои размышления. Не спросишь — не узнаешь!
Каким бы ни был результат, нет ничего плохого в том, чтобы высказать недопонимание. Гораздо хуже — оставить возникающие вопросы без ответов.
2. Вникайте в критерии приемки
Данное правило подразумевает, что, во-первых, вы знаете цель и задачи запроса на слияние, а во-вторых, понимаете, насколько выполненные изменения способствуют их реализации. Что касается критерием приемки, то здесь главное — детализация каждого уровня абстракции.
Для понимания этих критериев сначала следует просмотреть тикет, связанный с запросом на слияние. Он должен содержать описание общих целей и деталей реализации.
Если вы автор запроса, то не помешает сопроводить его описание дополнительными пояснениями и упоминаем о потенциальных проблемах. А можно пойти еще дальше и самому прокомментировать сложные фрагменты кода своего запроса, тем самым облегчая жизнь коллегам.
При проверке чужого запроса вам также не обойтись без знания критериев приемки. Просмотр списка изменений на GitLab точно не поможет в понимании кода. Вместо этого лучше притяните к себе (pull) саму ветку и поработайте с еще не известными вам изменениями. Поэкспериментируйте, запустите тестовые сценарии или проверьте, много ли времени требуется базе кода на создание или выполнение. Обнаружив ошибку или столкнувшись с чем-то непонятным, оставьте комментарий в ревью и действуйте согласно правилу #1.
3. Вносите только небольшие изменения
Запрос на слияние в размере 1,000+ строк ничего, кроме уныния, не вызывает. Скорее всего, никто не будет просматривать такой большой объем кода. В идеале запрос должен включать от 10 до 100 строк.
Сначала это может звучать пугающе, но существуют практические шаги для сокращения процесса ревью. Убедитесь, что файл .gitignore в порядке. Именно он указывает системе контроля версий Git на файлы, которые должны игнорироваться. Они могут быть связаны с IDE или основываться на зависимостях, возникших в результате работы с веб-фреймворком, например Angular.
Репозиторий github/gitignore содержит полезную подборку шаблонов файла
.gitignore.
Следующим советом вы можете воспользоваться сразу же: внедряйте в практику ежедневные ревью кода. При работе на GitLab можно изменить заголовок запроса, начав его с “WIP” (“Работа в процессе”) или “Draft” (“Черновик”). Это позволит коллегам по команде проверять и комментировать изменения в коде, но без возможности объединения их с целевой веткой.
Благодаря такому подходу команде доступна актуальная информация обо всех вносимых изменениях. Кроме того, отпадает необходимость проверять огромные объемы кода, в которых никому ничего на самом деле не понятно. И наконец, все больше участников команды понимают ваш код и берут на себя ответственность за него.
4. Четко формулируйте командные стандарты
А вы в курсе, что именно применяет ваша команда для Angular: верблюжий регистр (camelCase) или стиль нижних подчеркиваний (underscore_case)? Существует ли ограничение на количество строк функции для упрощения тестирования? Каков порог минимального покрытия кода? Есть ли место для совместно используемой функциональности и кода?
Будучи частью процесса совместной разработки, вы должны знать ответы на эти и многие другие вопросы. По-хорошему, у каждой команды должны быть стандарты документации. Если у вас таковых еще нет, то возьмите на себя инициативу по их созданию.
Если вы не пожалеете времени и задокументируете стандарты команды, то из первых рук узнаете ее лучшие практики и параллельно снабдите коллег реально полезным документом.
5. Соблюдайте баланс
Ревью кода — процесс не из легких. Нужно быть обстоятельным в ответах, но при этом не спамить коллег сообщениями, а также уважительным, но правдивым. Более того, необходимо самому проявлять инициативу, не ограничиваясь только предоставлением обратной связи. При ревью кода важно соблюдение баланса, поскольку кто-то любит общаться, а кто-то — нет.
Но в итоге все заканчивается совместным владением. Как только происходит слияние кода, он становится собственностью всей команды, и в этом случае уже не следует критиковать или хвалить кого-то конкретно. Решайте сами, каким образом лично вы можете посодействовать процессу ревью. Однако если вы принимаете на вооружение вышеуказанные правила, то важнейшим из них должно стать самое первое — делитесь своими мыслями.
В следующий раз, когда вы будете участвовать в ревью, задавайте вопросы. Если их нет, то предлагайте решения или даже отдайте должное чужому коду. Гораздо лучше получить обратную связь по своему запросу на слияние, будь то одобрение или критика, чем обнаружить полное ее отсутствие.
Заключение
Надеемся, статья вам понравилась, и какой-нибудь из советов пригодится для ваших собственных ревью.
Благодарю за внимание!
Читайте также:
- 5 ловких приемов Xcode для рефакторинга кода
- No-code и сферы его применения
- Антишаблоны программирования
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Israel Miles: 5 Rules for Every Code Review
