Если вы используете Subversion, плагин Peer Review Plugin для Trac предоставляет бесплатный вариант с открытым исходным кодом для проведения обзоров кода проектов. Плагин Peer Review Plugin интегрируется с проектом Trac с открытым исходным кодом, вики-страницей и системой отслеживания проблем для разработки проектов.
12 лучших инструментов для ревью кода для разработчиков (2020) Перевод
Обзор кода — это часть разработки программного обеспечения, при которой исходный код тестируется для выявления ошибок на ранней стадии. Процесс обзора кода обычно выполняется до слияния с кодовой базой.
Эффективный обзор кода предотвращает появление ошибок в проекте и улучшает качество кода на ранних стадиях процесса разработки программного обеспечения.
В этой статье объясняется, что такое обзор кода, и представлены популярные инструменты, которые помогают компаниям в этом процессе.
Что такое процесс ревью кода?
Основная цель обзора кода — проверить новый код на наличие ошибок и убедиться, что он соответствует стандартам качества, установленным компанией. Процесс рецензирования кода должен состоять не только из односторонней обратной связи. Таким образом, нематериальная выгода от обзора кода — это коллективное улучшение навыков написания команды.
Если вы хотите внедрить процесс обзора кода в своей компании, вам сначала нужно решить, кто должен проводить обзор кода. Если вы работаете в небольшой команде, вы можете поручить руководителям команды просмотреть весь код. В крупной организации с несколькими рецензентами следует установить процесс, при котором каждый рецензент назначается опытному разработчику в зависимости от его загруженности.
Затем вы должны определить сроки, последовательность и минимальные требования для принятия запросов на проверку кода.
Наконец, подумайте о том, как будет осуществляться обратная связь в процессе обзора кода. Обязательно подчеркните положительные стороны кодекса и предложите альтернативные варианты устранения обнаруженных недостатков.
Ваш отзыв должен быть достаточно конструктивным, чтобы разработчик понял ваши идеи и при необходимости инициировал обсуждение.
-Постарайтесь, чтобы комментарии были информативными.
Оценщики могут очень легко оказаться в «тупиковой» ситуации, что приведет к снижению эффективности или даже непродуктивности.
Почему ревью кода критичен?
Процесс рецензирования кода является критическим, поскольку он не похож на формальный процесс обучения в школах/университетах. Вы можете изучить тонкости языка программирования и управления проектами, но ревью кода — это процесс, который развивается, пока организация находится в «процессе разработки».
Проверка кода является критической, потому что она необходима:
- Позволить убедиться в отсутствии багов в коде.
- Минимизировать вероятность возникновения проблем.
- Подтвердить, что код придерживается заданных установок.
- Повысить эффективность нового кода.
Затем обзор кода приводит к улучшению навыков членов команды. В то время как ведущий программист
Полное руководство по ревью кода
Это случалось с каждым из нас. Вы целыми днями сидите и ждете, когда ваш код будет пересмотрен. А когда это происходит, вы играете в пинг-понг с рецензентом и пытаетесь повторно подать заявку для концентрации. И в течение нескольких недель вам приходится чередовать новые функции и старые сообщения, которые все еще нуждаются в исправлении.
Если процесс проверки кода не разработан должным образом, его «издержки» могут перевесить его преимущества.
Поэтому важно, чтобы у вашей команды была хорошая структура для процесса рецензирования кода.
В целом, у вас должны быть хорошие рекомендации как для рецензента, так и для ревьюера кода. В этих руководствах должно быть указано, что необходимо сделать до того, как группа представит обзор, и как будет проводиться обзор. Теперь перейдем к деталям.
- Уменьшение количества багов в коде.
- Дополнительная проверка удовлетворения всех требований.
- Эффективный способ учиться у коллег и знакомиться с кодовой базой.
- Поддержка определенного стиля кода внутри команды.
- Сплоченность команды: ревью кода подталкивают разработчиков к общению друг с другом на тему лучших подходов и стандартов кода.
- Улучшение качества кода под влиянием коллег.
Чем лучше вы передадите свой код рецензенту, тем менее рискованным он будет в долгосрочной перспективе. Следующие рекомендации помогут вам в этом:
Поскольку рецензент является последним звеном в цепи перед объединением кода, уменьшение количества ошибок в этом коде в значительной степени зависит от него. Рецензент должен:
Также следует избегать большого количества комментариев. Вы можете воспользоваться ревьювером Github (см. пример ниже).
Если у вас много комментариев, вам не нужно писать комментарий для каждого из них. Используйте опцию обзора на Github и отправьте уведомление разработчику (держателю PR), когда закончите.
В заключение я считаю, что следующие вопросы очень полезны для улучшения и облегчения процесса рецензирования кода:
Определяем необходимые условия для создания пул-реквеста
- Убедитесь, что ваш код успешно компилируется.
- Прочтите свой код, добавьте аннотации.
- Соберите и запустите тесты, соответствующие области вашего кода.
- Весь код кодовой базы должен быть протестирован.
- Сделайте ссылку на относящиеся к делу тикеты в вашем инструменте для менеджмента задач (например, JIRA).
- Не назначайте ревьюера, пока не сделаете все вышеперечисленное.
Существует множество эффективных подходов к проведению обзоров кода. Они варьируются в зависимости от потребностей каждой команды. Приведенная здесь схема — это лишь мое мнение; для вашей команды вполне может подойти что-то другое. При создании такого процесса следует учитывать цели вашей организации, культуру вашей команды и общую структуру развития.
- Коммуницируйте со своим ревьюером. Представьте ему бэкграунд вашей задачи. Поскольку большинству из нас уже доводилось самим выступать в роли интервьюера, просто постарайтесь встать на его место. Спросите себя, что могло бы облегчить задачу вам, если бы ревью этого кода делали вы.
- Делайте более мелкие пул-реквесты. Это лучший способ ускорить ревью. Маленький размер пул-реквеста сделает возможными более быстрые и аккуратные итерации. В целом, более мелкие изменения также легче тестировать и проверять на надежность. Когда ревьюер просматривает такой пул-реквест, ему легче понять контекст и логику.
- Старайтесь не вносить изменений в ходе ревью. Значительные изменения, внесенные в код, который как раз проходит ревью, сводят на нет все усилия ревьюера. Если вам все же необходимо внести какие-то крупные изменения, когда вы уже отправили заявку на просмотр, имеет смысл сначала отправить код в изначальном виде, а потом послать дополнительные изменения. Если внесение изменений понадобилось, когда процесс ревью уже начался, сообщите об этом ревьюеру как можно раньше.
- Отвечайте на каждый фидбэк. Даже если вы не собираетесь применить рекомендуемые изменения, напишите ответ и приведите свои доводы. Если в фидбэке вам что-то непонятно, задавайте вопросы.
- Ревью кода это дискуссия, а не предписания. Все фидбэки, полученные после просмотра вашего кода, стоит считать предложениями, а не приказами. Если вы не согласны с ревьюером, это прекрасно. Однако вы должны обосновать свою точку зрения и дать возможность оппоненту ответить на это.
Определяем обязанности ревьюера
Систематическая практика оценки кода внутри команды не всегда является разумным решением с точки зрения потребления ресурсов. Это отнимает много времени как у автора, так и у оценщика, а также требует глубокого понимания процессов и коммуникационных усилий.
- Ознакомиться с описанием задачи и требованиями.
- Убедиться, что он полностью понимает представленный ему код.
- Оценить все архитектурные компромиссы.
- Разделить свои комментарии на три группы: критически важные, опциональные и позитивные. В первую группу попадают изменения, которые разработчик обязательно должен внести. В последней будут комментарии, которые дадут разработчику понять, что вы оценили красоту отдельных частей его кода.
Причины отказа от проведения обзора кода в конкретном случае:
Причины отказа от постоянной практики обзора кода:
Перед началом процесса
- Возникают ли у меня трудности с пониманием этого кода?
- Есть ли в коде какие-то сложности, которые можно уменьшить путем рефакторинга?
- Хорошо ли организован код, продумана ли структура пакета?
- Являются ли имена классов интуитивно понятными, очевидно ли, что эти классы делают?
- Есть ли заметно большие классы?
- Есть ли какие-то особенно длинные методы?
- Все ли имена методов кажутся понятными и интуитивными?
- Хорошо ли документирован код?
- Хорошо ли он протестирован?
- Можно ли сделать этот код более эффективным?
- Соответствует ли этот код нашим командным стандартам стиля?
Причины, по которым можно избежать изменения кода: Почему бы не сделать изменение кода до начала обзора кода?
Когда нужно и не нужно проводить код-ревью?
Перед началом работы рецензенту необходимо оценить объем МР и определить, сможет ли он просмотреть его «на одном дыхании», не теряя концентрации внимания. Если МР слишком объемный, рекомендуется разбить его на более мелкие части. Чем больше раствор, тем менее эффективен контроль.
В первом раунде важно, чтобы экзаменатор
- нет человека, который обладает экспертизой в области специфики задачи;
- изменения слишком незначительны и не требуют проверки.
У команды должен быть набор правил, которыми она руководствуется при разработке программного обеспечения. Это необходимо для обеспечения последовательного стиля и облегчения понимания системы.
- у всех разработчиков одинаковый уровень знаний, навыков и уровень погружения в контекст;
- приняты другие практики проверки кода — например, парное программирование;
- постоянные конфликты из-за код-ревью в команде;
- практика уже показала свою неэффективность.
Как организовать процесс проверки кода?
Если автор решения выходит за рамки или отклоняется от принятых стилевых рекомендаций, полезно указать на это.
- После выполнения задачи автор кода делает в отдельной ветке push в удаленный репозиторий и создает Merge Request (MR).
- Назначается assignee (ответственный за MR) и reviewer (ответственный за проверку).
- Затем начинается серия проверок, которая называется раундами. Цель каждой итерации — найти проблемы и недочеты, которые могут отразиться на работе проекта в будущем.
→ Не трогайте код, выходящий за рамки данной статьи.
Решение должно быть реализовано в рамках задания. Если разработчик определил, что можно обновить другой класс, лучше всего сделать это в отдельном MR. Таким образом, оценщик может легче проверить, была ли выполнена первоначальная задача.
→ Просмотрите вкладыши, использованные в проекте.
Большинство команд в Selectel используют предварительное связывание — поэтому каждый раз, когда вы связываете, код проходит через лайнеры. Для Python используются black, isort, flake8, pyupgrade и autoflake.
→ Он легко читается и объясняет неочевидные моменты.
Лучшая практика в разработке — писать код, который сам себя документирует. Если по какой-то причине вы не можете им воспользоваться, хорошо бы оставить поясняющий комментарий: Это проинформирует рецензента о том, что происходит в этой части проекта.
Но не переусердствуйте с комментариями: Их количество увеличивает объем текста, который приходится читать другим разработчикам.
→ Если в проекте запланированы самотестирования, то решение должно быть охвачено ими.
Как понять, что решение готово?
Команда решает провести самотестирование для повышения надежности сервиса. Если такая практика уже существует, ее стоит поддержать. Когда выходят патчи, иногда тест нужно немного переписать, а когда выходят небольшие версии, всегда нужно писать новые.
→ Никакой чрезмерной инженерии (код «на будущее»).
- опечатки;
- ошибки, возникшие из-за недостаточного погружения в контекст проекта;
- необновленный конфигурационный файл.
Часто код, решающий проблемы, которые еще не возникли, не приносит пользы и становится избыточным.
Дональд Кнут сказал: Преждевременная оптимизация — корень всех проблем в программировании.
Перед началом
Круглый
Перед началом работы оценщик должен оценить объем MR и определить, можно ли проверить «все сразу» — без потери концентрации. Если МР слишком большой, рекомендуется разделить его на более мелкие части. Чем больше раствор, тем менее эффективен тест.
В первом раунде важно, чтобы тестировщик изучил код на предмет наличия глобальных проблем более высокого уровня. Это, например, неправильный подход к решению или разделение на функции, отсутствие модульности.
Если таких проблем не обнаружено, уровень проверки снижается до тех пор, пока не появятся возможности для улучшения.
В первом раунде не нужно концентрироваться на мелких недостатках. Автор с большей вероятностью найдет их, так что рецензенту не придется тратить время на поиски мелких проблем.
Антон Щербак, разработчик Selectel
Затем код возвращается автору: он/она вносит изменения и снова отправляет его на проверку. Процесс продолжается до тех пор, пока решение не будет признано приемлемым — оно утверждается рецензентом, после чего происходит слияние.
«Решение не обязательно должно быть идеальным — оно должно отвечать требованиям проекта и выполнять свою работу», — говорит разработчик Антон Щербак.
→ Отсутствие очевидных ошибок
Решение должно быть реализовано в рамках рабочего плана. Если разработчик заметил, что другой класс может быть обновлен, лучше сделать это в отдельном MR. Таким образом, оценщику легче проверить, было ли выполнено первоначальное задание.
→ Просмотрите вкладыши, использованные в проекте.
Большинство команд в Selectel используют предварительное связывание — это направляет код через лайнеры при каждой передаче. Для Python используются black, isort, flake8, pyupgrade и autoflake.
Как организовать процесс проверки кода?
Если автор решения выходит за рамки или отклоняется от принятых стилевых рекомендаций, полезно указать на это.
- После выполнения задачи автор кода делает в отдельной ветке push в удаленный репозиторий и создает Merge Request (MR).
- Назначается assignee (ответственный за MR) и reviewer (ответственный за проверку).
- Затем начинается серия проверок, которая называется раундами. Цель каждой итерации — найти проблемы и недочеты, которые могут отразиться на работе проекта в будущем.
→ Не трогайте код, выходящий за рамки данной статьи.
Решение должно быть реализовано в рамках задания. Если разработчик определил, что можно обновить другой класс, лучше всего сделать это в отдельном MR. Таким образом, оценщик может легче проверить, была ли выполнена первоначальная задача.
→ Просмотрите вкладыши, использованные в проекте.
Большинство команд в Selectel используют предварительное связывание — поэтому каждый раз, когда вы связываете, код проходит через лайнеры. Для Python используются black, isort, flake8, pyupgrade и autoflake.
→ Он легко читается и объясняет неочевидные моменты.
Лучшая практика в разработке — писать код, который сам себя документирует. Если по какой-то причине вы не можете им воспользоваться, хорошо бы оставить поясняющий комментарий: Это проинформирует рецензента о том, что происходит в этой части проекта.
Но не переусердствуйте с комментариями: Их количество увеличивает объем текста, который приходится читать другим разработчикам.
→ Если в проекте запланированы самотестирования, то решение должно быть охвачено ими.
Как понять, что решение готово?
Команда решает провести самотестирование для повышения надежности сервиса. Если такая практика уже существует, ее стоит поддержать. Когда выходят патчи, иногда тест нужно немного переписать, а когда выходят небольшие версии, всегда нужно писать новые.
→ Никакой чрезмерной инженерии (код «на будущее»).
- опечатки;
- ошибки, возникшие из-за недостаточного погружения в контекст проекта;
- необновленный конфигурационный файл.
Часто код, решающий проблемы, которые еще не возникли, не приносит пользы и становится избыточным.
Дональд Кнут сказал: Преждевременная оптимизация — корень всех проблем в программировании.
Перед началом
Круглый
Перед началом работы оценщик должен оценить объем MR и определить, можно ли проверить «все сразу» — без потери концентрации. Если МР слишком большой, рекомендуется разделить его на более мелкие части. Чем больше раствор, тем менее эффективен тест.
В первом раунде важно, чтобы тестировщик изучил код на предмет наличия глобальных проблем более высокого уровня. Это, например, неправильный подход к решению или разделение на функции, отсутствие модульности.
Если таких проблем не обнаружено, уровень проверки снижается до тех пор, пока не появятся возможности для улучшения.
В первом раунде не нужно концентрироваться на мелких недостатках. Автор с большей вероятностью найдет их, так что рецензенту не придется тратить время на поиски мелких проблем.
Антон Щербак, разработчик Selectel
Затем код возвращается автору: он/она вносит изменения и снова отправляет его на проверку. Процесс продолжается до тех пор, пока решение не будет признано приемлемым — оно утверждается рецензентом, после чего происходит слияние.
«Решение не обязательно должно быть идеальным — оно должно отвечать требованиям проекта и выполнять свою работу», — говорит разработчик Антон Щербак.
→ Отсутствие очевидных ошибок
Решение должно быть реализовано в рамках рабочего плана. Если разработчик заметил, что другой класс может быть обновлен, лучше сделать это в отдельном MR. Таким образом, оценщику легче проверить, было ли выполнено первоначальное задание.
→ Просмотрите вкладыши, использованные в проекте.
Большинство команд в Selectel используют предварительное связывание — это направляет код через лайнеры при каждой передаче. Для Python используются black, isort, flake8, pyupgrade и autoflake.
Советы по процессу
- Договоритесь о сроках и организации процесса. Например, не отдавайте правки по одной — это отвлекает. Еще не затягивайте процесс на весь день и по возможности не переключайтесь между задачами — это время- и энергозатратно.
- Используйте префикс NIT (сокращение от nitpick) для комментариев, которые даны в качестве рекомендаций. Помните: они не обязательны к исполнению, автор волен сам решать, следовать им или нет.
Лучшая практика в разработке — писать код, который сам себя документирует. Если по какой-то причине вы не можете им воспользоваться, хорошо бы оставить поясняющий комментарий: Это проинформирует рецензента о том, что происходит в этой части проекта.
- Помните о том, что обратная связь должна быть балансной. Ее цель — не обидеть человека, а аргументировано (например, с помощью примеров кода и ссылок на паттерны) подсветить зоны для улучшений. Кроме того, не зацикливайтесь только на ошибках: если видите интересное решение или нестандартный подход, похвалите его. Так лишний раз покажите коллеге, что у вас одна цель, и снимите напряжение.
- Количество раундов в код-ревью не ограничено, но лучше стремиться к сокращению их количества. Каждая новая серия правок отнимает силы участников ревью и тормозит релиз.
