Что такое проверки кода и как они экономят время

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

• Нет ли в коде очевидных логических ошибок?

• Полностью ли пригоден код для всех сценариев использования, описанных в требованиях к коду?

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

• Отвечает ли код требованиям существующего руководства по оформлению?

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

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

Проверка кода принесет пользу любой команде, вне зависимости от используемой методики работы. Она особенно полезна agile-командам, поскольку помогает распределить работу между разными сотрудниками.

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

Проверка кода способствует обмену знаниями

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

Специалисты широкого профиля могут выполнять работу как по клиентской, так и по серверной части.

Благодаря проверкам кода повышается точность оценки сложности работы

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

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

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

Проверка кода позволяет делать перерывы в работе

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

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

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

Проверки кода дают возможность обучения новых специалистов

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

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

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

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

Распределяйте нагрузку

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

Выполняйте проверку до слияния

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

Используйте социальное давление в своих интересах

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

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