Agile-команды работают по принципу самоорганизации, и наборы навыков у разных их участников могут пересекаться. Отчасти это достигается через проверку кода. Выполняя проверку кода, разработчики знакомятся с базой кода, а также осваивают новые технологии и приемы, которые способствуют развитию их навыков.
Так что же такое проверка кода?
Когда разработчик заканчивает выполнение задачи, другой разработчик анализирует получившийся код, принимая в расчет следующие вопросы.
- Нет ли в коде очевидных логических ошибок?
- Полностью ли пригоден код для всех сценариев использования, описанных в требованиях к коду?
- Достаточно ли покрывают добавленный код новые автоматические тесты? Нужно ли переписать существующие автоматические тесты для учета изменений в коде?
- Отвечает ли код требованиям существующего руководства по оформлению?
Проверки кода должны быть частью существующего рабочего процесса команды. Например, если в команде принято создавать ветки заданий, проверка кода должна начинаться после того, как весь код уже написан, автоматические тесты выполнены и успешно пройдены, но прежде, чем код будет объединен с вышестоящей веткой. Тогда лицо, проверяющее код, сможет уделить внимание тем участкам кода, которые не попали в поле зрения автоматики, и ошибки в коде не попадут в основную ветку разработки.
Какую пользу из проверки кода извлекает agile-команда?
Проверка кода пригодится любой команде, какой бы методике разработки она ни следовала. Agile-командам она особенно полезна, поскольку помогает распределить работу между разными сотрудниками. Ни один участник команды не является единственным знатоком того или иного фрагмента базы кода. Проще говоря, проверки кода являются инструментом обмена знаниями о базе кода между всеми участниками команды.
Проверка кода способствует обмену знаниями
В основе всех Agile-команд лежит небывалая свобода действий, поскольку все участники команды могут браться за работу из бэклога и выполнять ее. Как следствие, команды с большим энтузиазмом штурмуют новую работу, потому что задачи не зависят друг от друга. Специалисты широкого профиля могут выполнять работу как по клиентской, так и по серверной части.
Благодаря проверкам кода повышается точность оценки сложности работы
Вспомните раздел, посвященный оценке сложности. В этой процедуре участвует вся команда, и когда все участники одинаково хорошо знают продукт, можно точнее оценить объем и сложность работы. Когда возникает необходимость добавить в существующий код новые функции, его первый разработчик может поделиться своими знаниями и дать оценку сложности. Кроме того, все сотрудники, проверяющие код, получают сведения о трудностях, известных проблемах и особенностях, связанных с интересующим фрагментом базы кода. Следовательно, проверяющий обладает теми же знаниями об этом фрагменте кода, что и первоначальный разработчик. Таким образом, команда получает множество подкрепленных фактами исходных данных, на основе которых можно дать более точную и надежную окончательную оценку сложности.
Проверка кода позволяет делать перерывы в работе
Никто не хочет быть единственным человеком, отвечающим на все вопросы о том или ином участке кода. Никого также не прельщает необходимость заниматься критически важным участком кода, который написал кто-то другой, особенно во время нештатной ситуации в рабочей среде. Проверки кода способствуют обмену знаниями в команде, поэтому любой участник может принять эстафету и продолжить работу. Но главная польза кроется в другом: если критическими задачами занимается не один разработчик, значит, все участники процесса могут делать перерывы в работе. Если вам кажется, что вы стали заложником системы управления версиями, проверка кода будет прекрасным способом обрести свободу. Так вы сможете уйти в долгожданный отпуск или уделить время другой составляющей продукта.
Проверки кода дают возможность обучения новых специалистов
Еще одной отличительной особенностью agile является то, что, когда к команде присоединяются новые участники, их наставниками становятся более опытные специалисты. В ходе проверки кода они обсуждают базу кода. Часто в коде скрыты знания, неизвестные команде. Во время проверки они обнаруживаются. Новички привносят свой свежий взгляд и замечают неказистые, упущенные из виду из-за нехватки времени фрагменты базы кода, которые нужно пересмотреть. Как видите, благодаря проверке кода новая полезная информация обрамляется существующими знаниями.
При этом проверка кода не должна сводиться к надзору старших сотрудников за младшими. Любой участник команды может проверять код любого другого участника. У знаний не должно быть границ! Да, проверка кода может оказаться полезной новичкам, но ее ни в коем случае нельзя использовать только как инструмент наставничества.
Но на проверку кода уходит время!
Это правда, проверка отнимает время. Но это время не уходит впустую. Даже наоборот.
Оптимизировать затраты времени проверку кода можно тремя способами.
Распределяйте нагрузку
Многим командам в компании Atlassian приходится проводить две проверки каждого участка кода, прежде чем слить его с базой кода. Думаете, это значительно увеличивает накладные расходы? На самом деле, нет. Когда автор собирается назначить проверяющих, он выбирает из широкого круга участников команды. Проверить код могут любые два специалиста. Благодаря этому процесс децентрализуется, ни от одного человека не зависит вся работа, и в команде есть широкий выбор специалистов, способных поучаствовать в проверке кода.
Выполняйте проверку до слияния
Обязательная проверка кода до его слияния с вышестоящей веткой дает уверенность в том, что в рабочую среду не попадет непроверенный код. Это значит, что спорные архитектурные решения, принятые в 2 часа ночи, и ошибки, которые допустит стажер в использовании шаблона проектирования, будут выявлены прежде, чем смогут повлечь за собой долгосрочные (и досадные) последствия для приложения.
Используйте социальное давление в своих интересах
Когда разработчики знают, что их код будет проверять коллега по команде, они прикладывают дополнительные усилия, чтобы код успешно прошел все тесты и был написан максимально хорошо, чтобы проверяющий не столкнулся с трудностями. Благодаря такой осознанности сам процесс написания кода становится более отлаженным и, как результат, протекает быстрее.
Не стоит дожидаться проверки кода, если взгляд со стороны требуется на ранних этапах цикла разработки. Обратная связь на ранних этапах с последующими частыми комментариями способствует повышению качества кода, поэтому не стесняйтесь обращаться за помощью в любой момент времени. Это не только улучшит результаты вашей работы, но и разовьет навыки проверки у коллег. Вот такой вот замкнутый круг благоприятных последствий!
