В этой статье мы кратко рассмотрим 13 стандартов code review, которые могут значительно улучшить состояние вашего программного обеспечения, а также сделать ваших разработчиков счастливее.
Как следует из названия, code review — это процесс, при котором один или несколько разработчиков просматривают код, написанный другим разработчиком (автором), чтобы убедиться, что:
- в коде нет ошибок, нет ошибок или проблем
- он соответствует всем требованиям и стандартам качества и стиля
- код делает то, для чего предназначен
- при слиянии он не повредит кодовую базу
Вот почему проверка кода является важной частью разработки программного обеспечения. Ревьювер действует как привратник, который решает, может ли код стать частью кодовой базы и пойти в продакшн.
Google известен своим технологическим превосходством, и у них есть эффективные стандарты проверки кода, которые подчеркивают некоторые жизненно важные моменты, которые следует учитывать при проведении code review.
Основная цель проверки кода — убедиться, что общее состояние кода базы кода Google со временем улучшается, — документация по инженерным практикам Google.
Вот список вещей, которые следует учитывать при просмотре списка изменений (pull request).
Стандарты проверки кода
1. Код улучшает общее состояние системы
Каждые изменения (pull request) улучшают общее состояние системы. Идея состоит в том, что в результате таких небольших улучшений состояние программного обеспечения или кодовой базы будет улучшаться после каждого слияния.
2. Быстрая проверка кода, ответы и отзывы
Прежде всего, не откладывайте добавление (слияние) лучшего кода. Не ожидайте, что код будет идеальным. Если он находится в состоянии, улучшающем общее состояние системы, примите его.
Ключевым моментом здесь является то, что не существует такого понятия, как «идеальный» код — есть только лучший код, — документация Google.
Если вы не находитесь в середине конкретной задачи, проведите обзор кода вскоре после того, как он появится. Однако один рабочий день — это максимальное время, необходимое для ответа на запрос на pull request. Ожидается, что изменения (pull request) получат несколько раундов частичной/полной проверки кода за один день.
3. Обучайте и вдохновляйте во время проверки кода
Обеспечьте наставничество во время проверки кода, по возможности делясь знаниями и опытом.
4. При проверке кода соблюдайте стандарты
Всегда помните, что руководство по стилю, стандарты кодирования и подобные документы являются абсолютным авторитетом при проверке кода. Например, чтобы обеспечить согласованность между табуляциями и пробелами, вы можете ссылаться на соглашения о кодировании.
Если вы предпочитаете язык Java, то вам может быть полезна следующая статья, в которой дается краткое изложение передовых практик программирования на Java в крупных технологических компаниях: «Краткое изложение передовых методов программирования на Java».
5. Разрешение конфликтов при code review
Разрешайте конфликты, следуя согласованным передовым методикам, изложенным в руководстве по стилю и в стандартах кодирования, а также обращаясь за советом и предложениями к другим лицам, обладающим большими знаниями и опытом в продукте.
Если ваши комментарии являются необязательными или незначительными, то поясните это в своих комментариях и предоставьте автору право решать, рассматривать ли их или игнорировать.
Как рецензент кода, вы можете по крайней мере предложить, чтобы изменения (pull request) оставались совместимым с остальной частью кодовой базы в отсутствие руководства по стилю или стандартов кодирования.
6. Демонстрация UI изменений в рамках проверки кода
Если pull request изменяет пользовательский интерфейс, то в дополнение к обзору кода необходимо иметь демо, чтобы убедиться, что визуально все выглядит так, как ожидалось, и соответствует макетам.
Для изменений во front-end-е всегда рекомендуется создать демонстрацию/пошаговое руководство или убедиться, что список изменений также включает необходимые автоматизированные тесты пользовательского интерфейса, которые проверяют добавленную/обновленную функциональность.
7. Убедитесь, что проверка кода сопровождается всеми тестами
Если это не чрезвычайная ситуация, запрос на изменения должен сопровождаться всеми необходимыми тестами, то есть модульными, интеграционными, end-to-end и т.д.
Чрезвычайной ситуацией может быть ошибка или уязвимость, которые необходимо исправить как можно скорее, а тесты могут быть добавлены позже. В подобных случаях убедитесь, что создан соответствующий ticket/issue, и что кто-то взял на себя ответственность за их выполнение сразу после исправления или развертывания.
Нет достаточно веских причин, чтобы пропускать тесты. Если из-за нехватки времени некоторые цели могут не быть достигнуты, тогда решение состоит не в том, чтобы пропустить тесты, а в том, чтобы изменить цели на достижимые.
8. Когда вы сосредоточены, не отвлекайтесь на проверку кода
Если вы выполняете конкретную задачу, не прерывайтесь, так как на то, чтобы вернуться в нужное русло, может потребоваться много времени. Другими словами, стоимость отрыва от работы сфокусированного разработчика больше, чем ожидание другого разработчика прохождения проверки кода. Проверяйте код после запланированных перерывов, например, после обеда, кофе и т.д.
Не всегда можно проверить весь код за один день. Важно быстро дать автору обратную связь. Например, вы не сможете сделать полный обзор, но можете быстро указать на несколько вещей, на которые можно обратить внимание. Это значительно поможет уменьшить разочарование при проверке кода.
9. Просматривайте все и не делайте никаких предположений
Посмотрите на каждую строку кода, которую вам поручают просмотреть. Не делайте никаких предположений о классах и методах, написанных человеком, вы должны убедиться, что понимаете, что делает код.
Убедитесь, что вы понимаете код, который вы просматриваете. Если нет, уточните это или попросите пошаговое руководство/объяснение кода. Если есть часть кода, которую вы не имеете права проверять, убедитесь, что есть другие квалифицированные разработчики, которые могут проверить эти части кода.
10. Просматривайте код, помня о более широкой картине
Часто бывает полезно взглянуть на изменения в более широком контексте. Например, был изменен файл и добавлены четыре строки кода. Не просматривайте только четыре строки кода — вместо этого проверьте весь файл и новые добавления. Ухудшают ли они качество существующего кода или делают существующую функцию кандидатом на рефакторинг?
Если простые дополнения рассматриваются не в контексте функции/метода или класса, то со временем вы унаследуете класс, который не поддерживается, очень запутан, не тестируем, делает все, и его сложно расширять или рефакторить.
Помните, что так же, как небольшие улучшения со временем суммируются и приводят к отличному продукту с наименьшим количеством дефектов, точно так же небольшое ухудшение кода или технические долги с течением времени усугубляют и приводят к продукту, который сложно поддерживать и расширять.
11. Признавайте и поощряйте хорошую работу во время проверки кода
Если вы видите что-то хорошее в списке изменений, не забудьте поблагодарить автора за хорошую работу и поощрить его. Я лично раньше этого не делал. Целью проверки кода должно быть не только обнаружение ошибок, но и поощрение и наставление разработчиков за ту прекрасную работу, которую они делают.
12. Будьте внимательны, уважительны, добры и ясны при проверке кода
Очень важно, чтобы во время проверки кода вы были добрыми, ясными, вежливыми и уважительными, а также были очень ясны и полезны автору. При просмотре кода убедитесь, что вы написали комментарий о коде, а не о разработчике.
Вот руководство от Google о том, как проявлять уважение во время проверки кода: «Уважительные проверки кода: руководство для рецензентов кода».
13. Объясните свои комментарии в code review и помните об объеме
Каждый раз, когда в комментарии к обзору кода вы предлагаете альтернативный подход или на что-то намекаете, важно объяснить, почему, и привести пример, основанный на ваших знаниях и опыте, чтобы помочь разработчику понять, как ваше предложение поможет улучшить качество кода.
Предлагая исправления или изменения, найдите правильный баланс в том, как направить автора на исправления кода. Например, я ценю руководство, объяснение и некоторые советы или предложения, но не все решение.