РЕФАКТОРИНГ VS ПРОЦЕССЫ – ЧТО БУДЕТ ПЕРВЫМ

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

Первым будет вопрос от Дмитрия Алина @raiserspb про приоритеты – с чего следует начинать: со сложного рефакторинга продукта или с построения процессов.

Итак, вопрос:
Есть команда программистов, я тимлид. Команда работает с определенной скоростью, слажена, но не настроены процессы типа код-ревью, ретроспектива и тд. Код настолько мохнатый легаси, что в несколько раз замедляет работу. Проект гигантский и приносит тонны денег. Можно взяться за процессы, а можно спланировать рефакторинг, построить архитектуру и постепенно начать вводить процессы после первых этапов рефакторинга. За что хвататься и в каком порядке?

Ответ:
На мой взгляд, ключевым фактором в решении будет безопасность и управляемость. Рискну предположить, что если взяться сразу за рефакторинг, то многое может посыпаться, а вы про это узнаете, мягко говоря, не сразу. А поскольку, проект приносит тонну денег, то это огромные риски для бизнеса и для вас, получить потом по шеям.

Поэтому, я бы, в первую очередь, фокусировался на обеспечении безопасности и прозрачности проведения подобного рефакторинга. Подготовить устойчивую среду для такого глобального преобразования. Здесь и юнит-тесты/автотесты, и код-ревью, возможно управление поставками и репозиторием, какие то метрики работоспособности продукта и их мониторинг, разные уровни окружений и т п. Имея все это, рефакторинг можно делать безопасно, без оглядки на возможные проблемы обратной совместимости и работоспособности вообще.

В задаче рефакторинга это особенно важно, поскольку он не приносит явного value для бизнеса в моменте, т е чистые инвестиции. Если к инвестициям добавить еще и операционные потери от ухудшения качества продукта, то бизнес такого уже не простит.

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

Для примера могу привести общие правила и фреймворки change management: сначала подготовка и “разморозка”, определение показателей для контроля и подтверждения результата, потом само изменение, а потом “заморозка”. Вот без разморозки бросаться в омут рефакторинга очень рискованно.

P.S. По словам Дмитрия, ответить на вопрос получилось 🙂