Каталог решений - Реальный кейс по внедрению CodeReview

Реальный кейс по внедрению 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. Блок-схема распределения задач.