Как съесть слона или как мы нашли с какой стороны подойти к рефакторингу кода

Как отрефакторить код проекта? - Вопрос из цикла "Сколько стоит сайт" или "Сколько надо денег для счастья" - ответ соответствующий - It depends. Я не знаю "как на самом деле надо" или "Топ 10 очевидных советов от мнящего себя гуру". Это про то, как одна конкретная команда из HeliosX в работе над одним конкретным проектом (Dermatica) от разговоров о рефакторинге, смогла перейти к практике.

Контекст

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

Все вовлечённые люди (включая владельца компании, который бывший программист и сам писал первую версию этого монолита) прекрасно понимают количество звёзд имеющегося солюшна в категориях supportability, scalability, testability. Их не надо убеждать в необходимости сделать рефакторинг. Но как? С чего начать, чтобы звёзд СТАЛО больше, а клиентов НЕ СТАЛО меньше, и при этом работу над имеющимися задачами не прекращалась? Класическая "Быстро, Качественно, Дешево" где не хочется выбирать только два...

Слон

Как решалась проблема до сих пор? Да так же как большинство очень занятых людей решает проблемы со здоровьем - пока сильно не болит делаем вид, что проблемы нет, а потом "вырезаем" :). 

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

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

Новые - по любому, оба - долго. Но без старых, новый толком не сделать, да и переделывать придётся только 2м разработчикам, которые помнят как писалась и работает старая. 

А документировать до какого уровня по шкале С4? Это мы ещё не затронули рефакторинг - тут с какой области проекта начать? Подождите, мы же не определились по какому критерию делить проект на области...

Ушли мы с этого митинга в настроении чуть хуже чем до него. Мы понимали что этот слон большой и его надо будет есть по кусочкам, но он оказался не 3д а 4д и это мы ещё не со всех сторон его рассмотрели

NOTE: Вы можете очень по разному себе представлять митинги где обсуждаются какие-то сложные вопросы людьми с разными точками зрения. Чтобы ваша фантазия была ближе к реальности, зайдите в её настройки и: 

• сильно убавьте у персонажей эго
• выкрутите на максимум английскую вежливость
• не трогайте командное желание сделать как лучше (оно ведь и так было высоким)

вот такие у нас (пока) митинги ;)

Фонарик

HeliosX активно растёт и как все, "кто ходит в гости по утрам" - "поступает мудро"! Наш CEO осознаёт, что разные масштабы компании требуют разных подходов в управлении проектами и людьми, а набивать свои шишки - дорогое удовольствие, поэтому наряду с новым мотивированным скрам-мастером у нас есть новый мотивированный тех-консультант, который с нами аж 1 день в неделю :)

Признаться в начале работа этого парня у меня вызывала скептическую улыбку, т.к. мне казалось что он решает не существующую проблему. Но то каким полезным оказывается его тех-начитанность и жизненный опыт в целом в митингах по поеданию слонов - бесспорно. Он не решает за нас, не принимает активного участия в обсуждениях, но когда мы теряемся в этом тёмном сгустке возможностей он своим вопросом или правильной ссылочкой как фонариком подсвечивает возможный выход. Это может быть простой вопрос "Если бы ты мог переделать что-то одно, то что бы это было", это может быть ссылка на варианты документирования проектов, или статью о том как визуализировать необходимость рефакторинга в виде карты проблем в разных областях кода вытащенную из сонара. Это хороший кейс консультанта который помогает за счёт своего опыта. Ещё один пункт в списке карьерных опций для программиста ;)

Первый кусок слона

Я был тем самым "счастливчиком" которому надо было выбрать один единственный кусок для рефакторинга, а я хотел 3... У всех остальных своё видение. После примера визуализации проекта по Sonar issues, мы вдруг поняли что нам надо сделать то же самое - оцифровать и визуализировать субъективную проблему не пытаясь договориться по всем критериям!

Вот что мы сделали:

1. Выписали список областей на которые функционально делиться проект. По какому критерию? На сколько детально? А что если я вижу иначе? - не надо идеально, достаточно чтобы в целом все были согласны (помним про настройки поведения персонажей в вашей фантазии ;))
2. Каждый оценил по 5-ти бальной шкале необходимость в рефакторинге и как часто она (эта область кода) требует изменений. Чтобы не было расхождений в понимании того что такое 1 а что такое 5, договорились, что как минимум одна область должна иметь оценку 1, и минимум одна должна быть с оценкой 5. Ну, что было дальше легко догадаться
3. Вывели среднюю по обоим критериям и просуммировали, получив "первый кусок слона". Прожевать и переварить конкретный кусок мы в состоянии :)
4. Договорились повторять первые 3 пункта как только переварим выбранный

Ну элементарно же. Где тут супер рецепт, где тут вселенская мудрость? А нет её :). Наша задаче с одной стороны не требовала мозгов "Илона Маска" для решения, с другой, наш замыленный взгляд не смог разглядеть такой тривиальный подход к решению задачи.

С целью определились, дальше переходим в режим "Вижу цель, не вижу препятствий" ;)