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

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

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

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

Менеджер студии: проконсультировать клиента о возможных подходах и рисках. Помочь выбрать оптимальный вариант работы.

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

Во втором диалоге менеджер постарался объяснить, что рефакторинг будет происходить поэтапно. Но при этом ни в первом, ни во втором случае задача не была решена: бэклог для рефакторинга — это, конечно, хорошо, но для больших длительных проектов его написать будет очень проблематично. Просто потому, что по факту придётся перечитать весь бэкенд (рефакторинг касается именно его, в первую очередь).

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

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

Плюс в том, что вы рефакторите какой-то кусок, потом запускаете автотесты и с определенной долей вероятности можете быть уверены, что вы ничего не сломали и что нет регрессии. Серьёзный минус подхода с автотестами — это ОЧЕНЬ дорого (основные затраты — поддержка в актуальном состоянии), для сайтов — просто безумие по деньгам (а вот там, где критична стабильность — выходов нет, приходится раскошеливаться).


Ура, теперь вы знаете, что делать, если впереди вас ждёт пугающий рефакторинг. Если, смотря видео с поединками, вы вдруг осознали, что проседаете в ведении переговоров — советуем, как минимум, потренироваться на нашем онлайн-тренажере «Провокатор». А как максимум, — читайте книгу Владимира Завертайлова «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий"


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