Реальный кейс по внедрению CodeReview

Публикация № 1364611

Методология - Рефакторинг и качество кода

CodeReview ERP 1C

В различных источниках присутствует достаточно много теоретической информации о CodeReview, но вот описания реальных внедрений CodeReview встречаются редко. В данной статье будет минимум теоретической информации, а будет описан процесс внедрения 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. Блок-схема распределения задач.

 

Рисунок 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 были собраны основные выполненные задачи, которые помогли успешно внедрить данную процедуру.

  1. Разработать чек-лист (стандарт) для проведения CodeReview и согласовать его со всеми разработчиками;
  2. Разработать чек-лист для проверки архитектурных решений и согласовать его со всеми разработчиками;
  3. Донести до каждого разработчика значимость CodeReview;
  4. Каждый разработчик должен передать свои задачи на CodeReview, а также должен проверить по чек-листам задачи других разработчиков. У каждого разработчика должно быть понимание и опыт, как проводить CodeReview;
  5. Проведение совещаний с разработчиками по возникающим вопросам, обсуждение спорных моментов по CodeReview;
  6. Составить список наиболее часто встречающихся несоответствий стандарту разработки;
  7. Провести совещание (meetup) по наиболее часто встречающимся несоответствиям стандарту разработки;
  8. Согласовать доработки единой системы СУЗ в части CodeReview с руководителями проектов и разработчиками;
  9. Доработать единую систему СУЗ (руководителей проектов, консультантов и разработчиков) для проведения CodeReview.

 

Укрупненный план проектирования/составления/разработки в рамках CodeReview

В таблице 1 приведены задачи со сроками их выполнения и ответственными, которые необходимо было выполнить для достижения поставленных результатов по CodeReview. Многие пренебрегают тестовым запуском CodeReview, но именно он дал нам много обратной связи, и мы постоянно улучшали его до полноценного запуска. От момента начала тестового запуска до полноценного функционирования системы CodeReview прошло 6 месяцев. У нас происходил процесс CodeReview и разработка (модернизация) системы управления задачами параллельно. Каждый месяц все разработчики приобретали опыт в части CodeReview.

В части ответственных за CodeReview у нас было несколько разработчиков, которые вели и курировали все внедрение.

 

 
 Таблица 1 – укрупненный план проектирования/составления/разработки CodeReview.

 

Достигнутые результаты внедрения CodeReview:

            В данной главе приводятся те результаты, которые были достигнуты при внедрении CodeReview и что нам дал достигнутый результат:

1. Рост качества разработки команды (команда = целостность). Уменьшение затрат на разработку, т.к. ускоряется рост разработчика/команды;

2. Пишем хорошо, так как всех проверяют. Легче и качественней проходить внешние проверки нашего разработанного функционала;

3. Единый шаблон (стандарт) для всего отдела. Легче и качественней проходить внешние проверки нашего разработанного функционала;

4.Нахождение большого количества ошибок до Промышленной базы. Уменьшение затрат в промышленной эксплуатации, т.к. все несоответствия выявлены ранее;

5.Накопление/управления знаниями (можем смотреть, как и какая задача была реализована) (единая система учета знаний = СУЗ) (лучшее решение). Уменьшение затрат, т.к. многие решения уже будут готовы и их можно будет использовать;

6. Значительно легче поддерживать конфигурацию. Уменьшение затрат на обновления конфигурации, т.к. весь код написан по одному стандарту;

7. Уменьшение технического долга. Уменьшение затрат, т.к. в дальнейшем не нужно будет дорабатывать уже разработанный функционал;

 

Критерии для оценки результатов CodeReview

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

Количественные критерии:

  1. Количество «Красных» (критических) ошибок в промышленной эксплуатации (результат – почти полное их отсутствие);
  2. Количество гарантийных возвратов в промышленной эксплуатации (результат – почти полное их отсутствие);
  3.  Количество занесенных готовых решений в Базу знаний СУЗ для дальнейшего их использования в других решениях (результат - каждое готовое решение вносится в СУЗе);

 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.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. capitan 1901 23.01.21 18:30 Сейчас в теме
Очень толково. На чем в реальности собирали СУЗ, если не военная тайна ?
2. Alexsandr_Retunskiy 226 26.01.21 05:38 Сейчас в теме
(1) Думали сначала с нуля начать писать конфигурацию, но потом обнаружили хорошую конфигурацию на ИнфоСтарте - управление задачами (https://infostart.ru/public/552480/) , в тестовой эксплуатации собрали информацию для кастомизации от программистов, консультантов и руководителей проектов. Доработали конфигурацию.
Сейчас всех устраивает процесс СodeReview.

В статье не описал еще один момент, который у нас хорошо себя зарекомендовал - это канбан-доска, по ней удобно просматривать все свои задачи (которые на разработке, которые на CodeReview и т.д.). Канбан-доску тоже кастомизировали.
3. capitan 1901 26.01.21 12:19 Сейчас в теме
(2)Спасибо за ответ. Посмотрю.
Оставьте свое сообщение

См. также

Ускорение расчета себестоимости УПП 1.3 в несколько раз

Закрытие периода Рефакторинг и качество кода v8 УПП1 БУ УУ Бесплатно (free)

Как определить причину медленного расчёта себестоимости в УПП 1.3, один из вариантов поиска проблем производительности с помощью инструментов 1С и ускорения расчёта средствами встроенного языка

02.02.2021    1917    RPGrigorev    19    

Операторы перехода в программном коде: использовать или нет?

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Рассмотрим ситуации использования операторов перехода Перейти (GoTo), Возврат (Return), Прервать (Break), Продолжить (Continue). Как вы считаете - это дурной тон, нормальная практика или зависит от ситуации?

16.11.2020    1915    ivanov660    22    

Чистый кот (Clean cat)

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

От автора легендарного бестселлера "Совершенный кот".

04.11.2020    1560    vasilev2015    25    

Доработайте это "немедленно", или как уменьшить доработки конфигурации

Рефакторинг и качество кода v8 Россия Бесплатно (free)

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

25.09.2020    3666    Богатырев Артур    20    

Метод борьбы с большим количеством комментариев в коде

Практика программирования Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Решил поделиться нашим способом борьбы с сильно закомментированным кодом.

08.09.2020    1285    tambu    9    

Как поставить качество кода на поток и при этом не разориться? Какие шаги стоит сделать уже завтра, чтобы повысить планку качества?

Рефакторинг и качество кода v8 Бесплатно (free)

Наличие в 1С-решениях некачественного кода мешает их поддержке и эффективному развитию. Как добиться соблюдения стандартов разработки при написании кода и внедрить бюджетный Code Review с помощью инструментария на основе АПК (Автоматизированной проверки конфигураций) на конференции Infostart Event 2019 Inception рассказал технический руководитель компании Бизнес Лоджик Иван Козлов.

22.06.2020    3389    kozlov.alians    1    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Сценарное тестирование v8 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    4482    grumagargler    14    

Рефакторинг в редакторе модулей

Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Для тех, кто не пользуется Ctrl+Alt+R. “Контролируемый процесс улучшения кода без написания новой функциональности”, “Равносильное преобразование алгоритмов” и т.п в данной статье не рассматриваются. Тема статьи: замечательные команды из подменю Рефакторинг контекстного меню редактора модулей в конфигураторе. В статье описано, как команды из подменю Рефакторинг помогают при написании кода

10.03.2020    4171    pparshin    2    

Качество кода: Поведенческие паттерны проектирования

Рефакторинг и качество кода v8 Бесплатно (free)

Поговорим про применение паттернов проектирования в разработке на 1С.

03.03.2020    7706    ivanov660    0    

Боремся с запросами в циклах. Мой опыт рефакторинга запросов

Рефакторинг и качество кода v8::Запросы 1cv8.cf Бесплатно (free)

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

02.03.2020    7456    aximo    55    

Стабильность превыше всего

Рефакторинг и качество кода v8 Бесплатно (free)

Странная заметка о поддержании стабильности в условиях интенсивного изменения конфигурации.

07.11.2019    9764    YPermitin    40    

Оценка скорости кода. Сложность алгоритма

Практика программирования Рефакторинг и качество кода v8 1cv8.cf Бесплатно (free)

Эта тема одной из первых всплывает на собеседовании программистов языков вроде Java и C, но она почти неизвестна в "мире 1С". Поговорим о вычислительной сложности алгоритмов.

07.10.2019    5631    m-rv    12    

Управление качеством кода

Математика и алгоритмы Рефакторинг и качество кода v8 Бесплатно (free)

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    17783    Stepa86    33    

По следам код-ревью

Рефакторинг и качество кода v8 Бесплатно (free)

Приведу примеры с картинками и небольшим пояснением по вопросам, связанным с код-ревью (обзором кода).

09.07.2019    13174    ivanov660    110    

Что такое рефакторинг и в чем его цели

Практика программирования Рефакторинг и качество кода v8 Бесплатно (free)

Что такое рефакторинг, и в каких случаях им стоит заниматься? Евгений Шумилов дает ответы на эти вопросы, а также рассказывает о признаках хорошего и плохого кода. Кроме того, в статье приведены основные проблемы рефакторинга и способы их решения.

30.10.2018    11970    eu_genij    34    

Мастер-класс от Poppy (практикум по рефакторингу)

Практика программирования Рефакторинг и качество кода v8 1cv8.cf Россия Бесплатно (free)

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

04.11.2008    18792    poppy    32