Реальный кейс по внедрению CodeReview
Вступление:
Для тех, кто не использует CodeReview в своих компаниях, может показаться процесс внедрения тривиальным, но это не так. Даже запуская CodeReview на небольших командах разработчиков (3-5 программиста) можно столкнуться с рядом сложностей, о которых будет описано в данной статье.
В основном CodeReview ассоциируют с правильным написанием кода – это верно, но CodeReview может помочь решить ряд задач в компании, где он будет внедрен. В данной статье будут описаны результаты, которые были достигнуты с помощью CodeReview. Для оценки данных результатов будут приведены количественные и качественные критерии.
Для достижения ряда целей и при отсутствии необходимого бюджета, внедрение происходило с нуля, как оказалось, это дало много дополнительных плюсов. Не использовались готовые решения (sonarqube и т.д.). В первые месяцы внедрения не использовали даже автоматические проверки, но постепенно ряд рутинных процедур перевели на автоматическую проверку (данный пункт останется за рамками в статье, т.к. в рамках внедрения не использовали данные инструменты).
Внедрение CodeReview достаточно трудоемкий процесс. Чтобы добиться положительного результата внедрения необходимо будет выполнить ряд задач, которые будут описаны в данной статье. В статье будет приведен укрупненный план задач со сроками их выполнения и ответственными, это будет полезно для понимания примерных сроков внедрения CodeReview.
В статье подробно описывается и иллюстрируется в виде блок-схем весь жизненный цикл проверяющей задачи и взаимодействие в рамках CodeReview между основным разработчиком (тимлидом), консультантом, руководителем проекта, проверяющим программистом и ответственным разработчиком в единой системе управления задачами (СУЗ).
Единая система управления задачами (СУЗ)
Обязательным условием удачного внедрения CodeReview является наличие единой системы управления задачами для руководителей проектов, консультантов и программистов. Участвующее сотрудники в проекте должны отражать все задачи в данной системе, любое изменение конфигурации должно фиксироваться. В данной программе все задачи программиста, которые связаны с изменением кода должны проходить CodeReview по ранее согласованным стандартам (чек-листам) в компании или в рамках проекта. В данной статье не описываются стандарты (чек-листы) для проведения CodeReview, по данному пункту будет отдельная подробная статья.
Система управления задачами в рамках CodeReview позволяет проверяющему программисту быстро сориентироваться в задаче, т.к. СУЗ хранит всю иерархию задач. Можно быстро понять, какие задачи были сделаны ранее, связанные с новой задачей. Именно поэтому необходимо фиксировать все изменения в единой системе. Выбор проверяющего разработчика является отдельной задачей в рамках CodeReview. Проверяющего можно выбрать с помощью отдельного алгоритма (который должен учитывать доступность, нагрузку на программиста и т.д.) или назначать проверяющего программиста вручную тимлидом. Второй вариант у нас использовался при внедрении.
Консультант, руководитель проектов видят в СУЗе на каком статусе находятся задачи и какие задачи успешно или нет, прошли процедуры CodeReview.
Ответственный разработчик может отслеживать свои задачи по процедуре CodeReview: какие задачи возвращены на доработку, а какие успешно переведены в промышленную среду. По каждой задаче фиксируется лог ошибок/замечаний при их наличии.
Соответственно разработка и проверка задач должна происходить в тестовой среде разработки, которая имеет свое хранилище. В промышленную среду разработки, которая также имеет свое хранилище, должны попадать задачи, которые успешно прошли процедуру CodeReview.
План работ в системе управления задач по CodeReview
В данной главе подробно описывается план работ в системе СУЗ по CodeReview. Приводится блок-схема распределения задач (см. рисунок 1) и блок-схема взаимодействия консультанта, разработчика и проверяющего при CodeReview в системе СУЗ (см. рисунок 2). В зависимости от проекта некоторые пункты или последовательность пунктов может меняться, но общая концепция останется, как описано ниже.
Рисунок 1. Блок-схема распределения задач.
Рисунок 2. Блок-схема взаимодействия консультанта, разработчика и проверяющего при CodeReview.
Под тимлидом понимается главный разработчик (разработчик может быть в должности эксперт, ведущий разработчик, старший разработчик) на проекте, который отвечает за техническую архитектуру проекта и решает все спорные и сложные вопросы, связанные с разработкой на проекте.
1. Фиксация каждого требования/доработки (вплоть до мелких требований) консультантом в СУЗе (чтобы в дальнейшем можно было обратиться к каждому требованию/доработки). Фиксация в СУЗе связи с другими требованиями/доработками и ключевые решения консультант/разработчик.
По каждой задаче в СУЗе должны указываться: руководитель проекта, ответственный консультант, ответственный разработчик, ответственный проверяющий по CodeReview, функциональный блок, приоритет задачи, срок выполнения, сложность задачи.
2. По каждой задаче в СУЗе: приоритет задачи, срок выполнения и сложность задачи должны указываться совместно – руководителем проекта, консультантом и тимлидом.
3. Тимлид на проекте назначают ответственных разработчиков по задачам. Отмечают ответственного разработчика в СУЗе.
4. В СУЗе, должна быть отметка взятия в работу задачи разработчиком. Разработка ведется в тестовой среде разработки.
Крупные разработки по возможности должны делиться на более мелкие разработки, чтобы они быстрее разрабатывались и быстрее проходили CodeReview.
5. В СУЗе, должна быть отметка выполнения задачи разработчиком. Возможна фиксация ключевых решений разработчиком в СУЗе.
6. Проверка каждой доработки разработчиков (в идеале занимает не более часа у проверяющего разработчика) в тестовой среде разработки. Проверяющего разработчика должна определять система (по определенной матрице) или тимлид. Проверка должна осуществляться на соблюдении стандартов разработки (чек-лист проверки) и качества архитектурных решений. Должна быть отметка в СУЗе, что доработка ушла на CodeReview.
Ответственным за проведение CodeReview по всем доработкам проекта является руководитель проекта (или тимлид).
7. Выдача обратной связи по каждой проверенной доработки в СУЗе (пустых комментариев по задаче не должно быть). Фиксация ключевых ошибок/выполненных решений по доработкам в СУЗе. Возможно изменение/улучшение чек-листа проверки. Должна быть отметка в СУЗе, что выполнен CodeReview с результатами проверки.
8. В случае ошибок/замечаний по доработке происходит возврат к исполнителю на исправление (в идеале не более одного-двух часов на исправление, исключение серьезные ошибки). Должна быть отметка в СУЗе, что доработка вернулась на исправление по результатам проверки CodeReview.
Затем повторить шаги 4-7 (повторная разработка и повторный CodeReview). В СУЗе должна храниться вся история разработки/проверки доработки и должны быть отдельные статусы для повторной разработки/проверки.
9. В случае успешного прохождения CodeReview данная доработка отмечается отметкой в СУЗе, что она выполнена и прошла CodeReview.
10. После успешного прохождения CodeReview доработка передается на тестирование ответственному консультанту. Должна быть отметка в Сузе, что доработка находится на тестировании у консультанта.
11. В случае ошибок/замечаний по доработке происходит возврат к исполнителю на исправление. Должна быть отметка в СУЗе, что доработка вернулась на исправление при проверке консультантом.
Затем повторить шаги 4-10 (повторная разработка, повторный CodeReview и повторная проверка консультантом). В СУЗе должна храниться вся история разработки/проверки доработки и должны выделиться отдельные статусы для повторной разработки/проверки.
12. В случае успешного прохождения проверки консультантом данная доработка отмечается отметкой в СУЗе, что она выполнена и прошла проверку консультантом.
13. Тимлид переносит проверенные доработки по CodeReview и консультантом из тестовой среды разработки (из хранилища разработки) в промышленную среду разработки (в промышленное хранилище). В регламентированные часы происходит обновление промышленной базы. В СУЗе отмечается, что доработка перенесена в промышленную базу.
Переносятся в промышленную базу только доработки, которые успешно прошли CodeReview и проверку консультантом.
В случае если готовая доработка и непроверенная доработка находятся в тестовом хранилище и изменяют один объект, то такая доработка не переносится в промышленное хранилище.
Иные случая переноса доработок (например: когда доработка не прошла CodeReview или нужно срочно выложить доработку) в промышленное хранилище решаются тимлидом совместно с руководителем проекта.
14. Общее собрание разработчиков (один раз по итогам месяца) (обсуждение лучших и спорных решений) проводятся внутри проекта, так и по всем проектам вместе. Внутри проекта организовывает и проводит собрания тимлид.
Задачи для внедрения CodeReview
После внедрения CodeReview были собраны основные выполненные задачи, которые помогли успешно внедрить данную процедуру.
- Разработать чек-лист (стандарт) для проведения CodeReview и согласовать его со всеми разработчиками;
- Разработать чек-лист для проверки архитектурных решений и согласовать его со всеми разработчиками;
- Донести до каждого разработчика значимость CodeReview;
- Каждый разработчик должен передать свои задачи на CodeReview, а также должен проверить по чек-листам задачи других разработчиков. У каждого разработчика должно быть понимание и опыт, как проводить CodeReview;
- Проведение совещаний с разработчиками по возникающим вопросам, обсуждение спорных моментов по CodeReview;
- Составить список наиболее часто встречающихся несоответствий стандарту разработки;
- Провести совещание (meetup) по наиболее часто встречающимся несоответствиям стандарту разработки;
- Согласовать доработки единой системы СУЗ в части CodeReview с руководителями проектов и разработчиками;
- Доработать единую систему СУЗ (руководителей проектов, консультантов и разработчиков) для проведения CodeReview.
Укрупненный план проектирования/составления/разработки в рамках CodeReview
В таблице 1 приведены задачи со сроками их выполнения и ответственными, которые необходимо было выполнить для достижения поставленных результатов по CodeReview. Многие пренебрегают тестовым запуском CodeReview, но именно он дал нам много обратной связи, и мы постоянно улучшали его до полноценного запуска. От момента начала тестового запуска до полноценного функционирования системы CodeReview прошло 6 месяцев. У нас происходил процесс CodeReview и разработка (модернизация) системы управления задачами параллельно. Каждый месяц все разработчики приобретали опыт в части CodeReview.
В части ответственных за CodeReview у нас было несколько разработчиков, которые вели и курировали все внедрение.
Достигнутые результаты внедрения CodeReview:
В данной главе приводятся те результаты, которые были достигнуты при внедрении CodeReview и что нам дал достигнутый результат:
1. Рост качества разработки команды (команда = целостность). Уменьшение затрат на разработку, т.к. ускоряется рост разработчика/команды;
2. Пишем хорошо, так как всех проверяют. Легче и качественней проходить внешние проверки нашего разработанного функционала;
3. Единый шаблон (стандарт) для всего отдела. Легче и качественней проходить внешние проверки нашего разработанного функционала;
4.Нахождение большого количества ошибок до Промышленной базы. Уменьшение затрат в промышленной эксплуатации, т.к. все несоответствия выявлены ранее;
5.Накопление/управления знаниями (можем смотреть, как и какая задача была реализована) (единая система учета знаний = СУЗ) (лучшее решение). Уменьшение затрат, т.к. многие решения уже будут готовы и их можно будет использовать;
6. Значительно легче поддерживать конфигурацию. Уменьшение затрат на обновления конфигурации, т.к. весь код написан по одному стандарту;
7. Уменьшение технического долга. Уменьшение затрат, т.к. в дальнейшем не нужно будет дорабатывать уже разработанный функционал;
Критерии для оценки результатов CodeReview
Для проверки достигнутых результатов были составлены количественные и качественные критерии. Также приводятся результат, который был достигнут на одном проекте с применением процедур CodeReview.
Количественные критерии:
- Количество «Красных» (критических) ошибок в промышленной эксплуатации (результат – почти полное их отсутствие);
- Количество гарантийных возвратов в промышленной эксплуатации (результат – почти полное их отсутствие);
- Количество занесенных готовых решений в Базу знаний СУЗ для дальнейшего их использования в других решениях (результат - каждое готовое решение вносится в СУЗе);
4. Уменьшение затрат на обновление кастомизированных конфигураций (результат -все кастомизации происходят по стандарту, такие конфигурации легче обновлять).
Качественные критерии:
5. Рост качества разработки каждого разработчика, как следствие всей команды (результат – вся команда разрабатывает код по одним стандартам и весь код каждого разработчика проходит через CodeReview, приводит к единому высокому качеству кода каждого разработчика и всей команды).
6. Легче и качественней проходить внешние проверки разработанного функционала (кода) (результат – из-за единого высокого качества кода команды, легче и проще проходить внешние проверки разработанного функционал (кода)).
Сложности внедрения CodeReview:
В данной главе описываются возникшие сложности при внедрении CodeReview, с которыми, вероятнее всего, придется столкнуться каждому, кто будет внедрять CodeReview и решения данных сложностей:
1. Непонимание проведения процедуры CodeReview сотрудниками. Обсуждение с «отрицающими» CodeReview на собраниях, индивидуальные беседы с тимлидом/руководителем проекта, внесение в устав команды проведения CodeReview, управленческие решения.
2. Отсутствия времени разработчиками на проведения процедуры CodeReview. Составление каждым программистом планов на день с учетом CodeReview. Внесение времени CodeReview руководителем проекта и тимлидом в проект. Внесение в устав команды проведения CodeReview, управленческие решения.
3. Отсутствия бюджета для проведения процедуры CodeReview. Заложения затрат на процедуры CodeReview в проект. Донесения значимости CodeReview до клиента. Управленческие решения.
4. Отсутствия инструмента (СУЗ) для проведения процедуры CodeReview. Не нужно ждать пока будет, разработана СУЗ, нужно с чего-то начинать (фиксировать в любом тестовом редакторе), параллельно собирать обратную связь и разрабатывать (модернизировать) инструмент для CodeReview.
5. Изменения концепции разработки с учетом процедуры CodeReview. Необходимо две среды разработки – тестовая и промышленная. Вся разработка и процедуры CodeReview должны происходить в тестовой среде. В промышленную среду должны перемещаться только проверенные задачи.
Заключение:
Внедрение CodeReview достаточно сложный процесс, который хотя кажется со стороны полностью понятным и простым («проверяй чужой код и все»). Внедрение CodeReview заканчивается на первых месяцах, не достигнув особых результатов. Причин не удачных внедрений достаточно много, один из основных моментов – это не проводятся тестовые запуски процедур CodeReview в своих компаниях, именно они у нас показали ряд сложностей; выявили моменты, которые нам необходимо было улучшить и изменить для внедрения CodeReview.
У внедрения CodeReview обязательно должны быть ответственные разработчики, которые должны будут курировать весь процесс. Понимание и значимость CodeReview должно быть у всей команды, возможно не сразу, но это должно вырабатываться у каждого сотрудника, иначе все внедрение может постепенно сойти на нет. Еще один важный момент при внедрении CodeReview это бюджет проекта должен включать процедуру CodeReview, затраты на проверку кода должны быть заложены в проект.
CodeReview неразрывно связан с системой управления задачами, если в компании нет данной системы, то успешно внедрить его будет проблематично, т.к. на проектах многие задачи могут быть связаны по иерархии с десятками других задач и проверяющему программисту необходимо будет быстро сориентироваться в новой задаче.
CodeReview помимо основного результата, что команда пишет код правильно и в одном стиле, может еще помочь достигнуть ряд результатов. Основным, из которых я считаю - это профессиональны рост каждого разработчика (даже опытных). Проверяя и читая чужой код, рост программистов происходит быстрее, что является отличным плюсом внедрения CodeReview.
В данной статье описаны: задачи, которые необходимо будет выполнить в рамках внедрения: сложности с которыми придется столкнуть при внедрении, но в противовес им приводятся те результаты, которые могут быть достигнуты при успешном внедрении CodeReview.
