Комментарии
Продолжаем управленческие поединки с подробным разбором кейсов
Project Manager Skills: грядущий рефакторинг
Сибирикс
Project Manager Skills:
грядущий рефакторинг
Продолжаем управленческие поединки с подробным разбором кейсов
В прошлой серии: мы разобрали, что делать, если клиент предоставляет собственные макеты, да ещё и сам хочет писать бэкенд. Ситуация, как минимум, нетипичная, но выход есть всегда. В сегодняшнем кейсе не менее сложная задача — приближается рефакторинг, и надо как-то грамотно к нему подойти.
Ситуация
Постоянный клиент студии, у которого есть масштабный интернет-магазин с высокой посещаемостью и постоянными доработками-переработками, только что разработал еще один магазин с этой же студией. Итого, у него уже два магазина. Результатом остался очень доволен. Новый магазин получился шустрее старого, поскольку был использован более чистый код, без рудиментов старого, годами копившегося кода. Клиент хотел бы иметь такую же кодовую базу и на первом интернет-магазине. А в перспективе — сделать мобильное приложение для первого магазина.

Роли и интересы

Клиент: понять, как будет идти работа по обновлению кода первого магазина так, чтобы ничего не потерялось и не испортилось в процессе рефакторинга.

Менеджер студии: проконсультировать клиента о возможных подходах и рисках. Помочь выбрать оптимальный вариант работы.
Что произошло?
В первом диалоге заказчик завалил вопросами менеджера, и тот растерялся, хотя изначально выбрал верную стратегию рассказать о двух возможных вариантах рефакторинга. Но при этом заказчик, понимая что менеджер растерялся, пытался помочь ему и кое-где подсказывал :)

Во втором диалоге менеджер постарался объяснить, что рефакторинг будет происходить поэтапно. Но при этом ни в первом, ни во втором случае задача не была решена: бэклог для рефакторинга — это, конечно, хорошо, но для больших длительных проектов его написать будет очень проблематично. Просто потому, что по факту придётся перечитать весь бэкенд (рефакторинг касается именно его, в первую очередь).
Разбор кейса
Возможные стратегии рефакторинга
Возможные стратегии рефакторинга
Что выбрать
Когда заходит речь о рефакторинге кода, который долго изменялся и дописывался, в котором потенциально могли ковыряться другие разработчики, либо который очень долго перерабатывался, любой разработчик вам скажет: надо все нахрен переписать. Здесь подразумевается, что старый код — г-но, а новый он сделает классный и чистенький. Если вы не сто лет в отрасли, либо просто морально слабее разработчика, ему удастся вас продавить на такой сценарий. И аргументов переубедить разработчика у вас, скорее всего, не будет. Кстати, бывает что разработчик абсолютно прав, и ситуация именно «господь, жги, тут уже ничего не исправить». Тут нужен опыт, опыт и опыт, чтобы отличить желание от необходимости.

Мне больше импонируют варианты с API и мобильным приложением и рефакторинг по частям. Вариант с Code Freeze не нравится по причине подхода «давайте сейчас все нахрен перепишем». Вот вам неудобные, отрезвляющие вопросы без ответов:

  • Где гарантия, что мы знаем объем «всего» на старте?
  • А если внезапно выяснится, что «всего» гораздо больше, а на старте мы видели только верхушку айсберга?
  • За чей счёт будет этот банкет?
  • Где гарантия, что новый код будет в разы лучше старого?
  • А что будет, если нет?

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

Владимир
CEO & Founder
Как сделать, чтобы никакой функционал из старого бэкенда не потерялся?
Рецепт простой: короткие бэклоги для коротких кусочков кода, следом тест — если всё ок, идём дальше. Если вдруг есть возможность, то лучше покрыть систему автотестами в критических местах. В случае с API и интеграциями автотесты работают неплохо, а вот покрыть ими интерфейс — муторно и нужно много мощного железа.
В SingularityApp мы используем 6 мощных серверов на примерно пару тысяч интеграционных тестов интерфейсов, и это дает задержку от получаса до часа на тестирование (в зависимости от того, сколько коммитов стоит в очереди на проверке). Можно добавлять еще серверов, но это дорого. Unit-тесты работают несравненно шустрее, однако ими можно проверить далеко не всё.
Наше железо для автотестов SingularityApp (суммарный бюджет больше полумиллиона)
Плюс в том, что вы рефакторите какой-то кусок, потом запускаете автотесты и с определенной долей вероятности можете быть уверены, что вы ничего не сломали и что нет регрессии. Серьёзный минус подхода с автотестами — это ОЧЕНЬ дорого (основные затраты — поддержка в актуальном состоянии), для сайтов — просто безумие по деньгам (а вот там, где критична стабильность — выходов нет, приходится раскошеливаться).


Ура, теперь вы знаете, что делать, если впереди вас ждёт пугающий рефакторинг. Если, смотря видео с поединками, вы вдруг осознали, что проседаете в ведении переговоров — советуем, как минимум, потренироваться на нашем онлайн-тренажере «Провокатор». А как максимум, — приходите на наш курс по управлению проектами, всему научим!


Ну и напомним про Ютуб-канал: там регулярно выходит много интересного!