Зачем нужны проверки кода (и как они экономят время)

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

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

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

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

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

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

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

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

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

Это правда, проверка отнимает время. Но это время не уходит впустую. Даже наоборот.

Оптимизировать затраты времени проверку кода можно тремя способами.

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

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

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

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