Обзоры кода

Почему обзоры кода имеют значение (и на самом деле экономят время!)

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

Agile команды самоорганизуются, с наборами навыков, которые охватывают всю команду. Это достигается, в частности, с помощью обзора кода. Обзор кода помогает разработчикам изучать кодовую базу, а также помогает им изучать новые технологии и методы, которые расширяют их навыки.

Итак, что же такое ревью кода?

Когда разработчик заканчивает работу над задачей, другой разработчик просматривает код и рассматривает такие вопросы, как:

• Есть ли очевидные логические ошибки в коде?
• Глядя на требования, все ли случаи полностью реализованы?
• Достаточно ли новых автоматических тестов для нового кода? Нужно ли переписывать существующие автоматизированные тесты, чтобы учесть изменения в коде?
• Соответствует ли новый код существующим руководствам по стилю?

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

Что в этом для  agile команды?

Каждая команда может извлечь пользу из анализа кода независимо от методологии разработки. Agile команды, однако, могут принести огромные преимущества, потому что работа децентрализована по всей команде. Никто не является единственным человеком, который знает конкретную часть базы кода. Проще говоря, обзоры кода помогают облегчить обмен знаниями между всей базой кода и всей командой.

Кодовые обзоры делятся знаниями

В основе всех agile команд лежит непревзойденная гибкость: способность снять работу со списка необходимых требований (backlog) и начать выполнение всеми членами команды. В результате команды могут лучше копаться в новой работе, потому что никто не является «критическим путем». Инженеры полного стека могут заниматься как интерфейсной, так и серверной работой.

Ревью кода делают для лучших  оценок

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

Ревью кода позволяет отключить время

Никто не любит быть единственной точкой контакта на куске кода. Точно так же никто не хочет погружаться в критический кусок кода, который они не написали, особенно во время непредвиденной ситуации производства. Обзоры кода делятся знаниями в команде, так что любой член команды может взять на себя управление и продолжать управлять кораблем. (Мы любим смешанные метафоры в Atlassian!) Но вот в чем суть: ни у одного разработчика нет критического пути, это также означает, что члены команды могут взять отпуск по мере необходимости. Если вы обнаружите, что привязаны к рабочему столу в системе контроля версий, ревью кода - отличный способ обрести свободу. Свобода взять этот необходимый отпуск или свобода проводить некоторое время, работая над другой областью продукта.

Кодовые ревью наставляют новых инженеров

Особенностью Agile является то, что когда новые члены присоединяются к команде, более опытные инженеры наставляют новых членов. А проверка кода помогает облегчить разговоры о базе кода. Часто команды имеют скрытые знания в коде, которые всплывают во время проверки кода. Новые участники, со свежим взглядом, обнаруживают мрачные, измученные временем области кодовой базы, которые требуют новой перспективы. Таким образом, проверка кода также помогает гарантировать, что новое понимание будет смягчено существующими знаниями.

Но ревью кода требуют времени!

Конечно, они занимают время. Но это время не потеряно - это далеко от этого.

Вот три способа оптимизации для этого.

 

Поделитесь нагрузкой

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

Обзор перед слиянием

Требование ревью кода перед слиянием с вышестоящим потоком гарантирует, что ни один код не попадет в "не просмотренные". Это означает, что сомнительные архитектурные решения, принятые в 2 часа ночи, и ненадлежащее использование заводского образца стажером обнаруживаются до того, как они смогут оказать длительное (и прискорбное) влияние на ваше приложение.

Используйте давление со стороны равных по положению в ваших интересах

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

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

По материалам Agile Coach "Code review"