Модернизация легаси-системы: как выбрать между доработкой, рефакторингом и переписыванием

Давайте познакомимся

Автор статьи — технический директор IT-компании vverh.digital со стажем более 8 лет, и это только в разработке. За это время приходилось сотни раз слышать подобные фразы от программистов. Приходилось даже переделывать проекты с нуля, но чаще получалось реанимировать. Причём реанимация происходит не за счёт кода, а совсем иных вещей. Но об этом как раз сейчас и поговорим.

Слушайте команду, но слепо не доверяйте

Есть русская пословица: доверяй, но проверяй. Этот раздел как раз про это.

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

На этом этапе важно услышать версию каждого — это нам поможет в дальнейшем. Если это прихоть одного специалиста, тогда игнорируйте. Если об этом говорят многие — проблема существует. Но поможет ли переписывание?

Когда НЕ надо переписывать

1. Устарела кодовая база

Программисты говорят, что «что-то там» устарело. А что именно?

Библиотека или фреймворк, на котором построен сервис, устарели? Просто обновите. Версия языка старая? Поднимите. 

Да, будут проблемы, но всё можно исправить. Программисту придётся поработать.

Давайте расскажем пример из нашей практики: программист не смог подключить Firebase в одном из Node.js-проектов, для этого нужна была версия Node.js 14+. Проект был написан на 8. Естественно, когда программист в тупую поднял версию языка программирования — всё сломалось, он сказал: «Надо все переписывать». Автор статьи очень разозлился и решил проверить, почему это произошло. Как оказалось, старые библиотеки отказывались работать на Node.js 14. Поэтому автор за пару часов обновил несовместимые библиотеки на их более новые версии. Как итог — всё заработало.

Вопрос в зал: «Надо было разве переписывать всё из-за этого?». Ага, конечно.

Вердикт: если устарела кодовая база — только точечное обновление, а не полное переписывание.

2. Сложно добавлять функционал

Если доработка выкатывается в продакшен за потенциальную половину срока копии проекта — это ненормально. Но проблема ли в коде или, может быть, в процессах?

По опыту скажем сразу — беда в процессах. Тут надо копнуть в самый корень бизнес-процесса компании: 

• Как фича попадает в прод?
• Тестируют ли?
• Кто и когда тестирует?
• Кто-то вообще проверяет код? Да-да, сам код кто-то смотрит?
• Кто оценивает задачи? 
• Есть ли аналитика перед оценкой?

Мелкие стартапы игнорируют эти базовые вещи, думая, что экономят свои деньги на разработке, а на самом деле это не так — деньги просто сливают в унитаз. Потому что разработка начинает жрать много времени.

Если это аутсорсинговая компания, ей без разницы — она ведь тратит не свои деньги. А вот стартапы и компании со своим IT-отделом — наоборот, они уже лупят по своему бюджету.

Этот цикл не закончится, пока процессы IT-компании не обретут адекватный вид.

Есть задача? Отлично, сначала анализируем, что нужно сделать и сколько времени это займёт. Обязательно тащим разработчика на созвон с аналитиком, если последнему это необходимо. Если разработчику не хватает времени оценить (дали мало времени) — пусть берёт столько времени, сколько нужно. 

Потом всё собираем и ставим задачу. Реализуем и тестируем. Причём код разработчика должен посмотреть более опытный товарищ, чтобы не было плохого кода. Тестер же прогоняет все нужные тесты в зависимости от сделанной фичи. 

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

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

Вердикт: проверьте процессы разработки. Разработку можно превратить в понятный конвейер с чёткими временными рамками.

3. Каждая фича всё ломает

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

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

Иногда может хватить внедрения программного тестирования: unit-тесты, автотесты. Иногда пара таких тестов решает большую часть проблем с поломками на проде. Они просто не дойдут до этого этапа. Ну а внедрение мануального (ручного) тестирования — это вообще высший пилотаж.

Вердикт: внедрите тесты. Не помогло — проблема в процессах.

4. Проект тормозит

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

Во-первых, есть такой термин — оптимизация. Это значит провести какие-то манипуляции, чтобы ПО работало лучше. 

Во-вторых, некоторые оптимизационные мероприятия занимают очень мало времени.

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

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

А если проблема в нагрузке, то вообще достаточно сервер мощнее купить. Многие за хостинг платят по 1000 рублей в месяц. Вы думаете, за 1000 рублей получите нормальное железо? Нет, это будет огрызок огрызка. Хостер берёт нормальный сервер, разбивает его на кучу виртуальных, чаще с оверселом (завышает мощности), и продаёт Вам. Только так хостеры делают плюсовую маржу.

Но иногда проблема в скорости работы проекта бывает куда проще — проект написан криво из-за отсутствия контроля.

Пример: стажёры делают сотни запросов в цикле вместо одного SQL-запроса. То есть вместо того, чтобы взять один раз все поля для всех элементов, они в цикле перебирают каждый элемент и берут для него все поля. Автор статьи тоже так делал, будучи ещё зелёным и начинающим разработчиком. При слабом контроле таких мест в проекте могут быть десятки.

Вердикт: найдите узкие места, оптимизируйте. Не помогает — переписывайте узкие места.

5. Устарели технологии

А это вообще смешной аргумент. Мир IT постоянно меняется, новые JavaScript-фреймворки выходят каждый день. Теперь что, каждый день всё переписывать? Java (не путать с JavaScript) вышла 23 января 1996 года, и до сих пор есть проекты, написанные на ней. Да, новые модули делать на Java сейчас — странное решение, но так почти никто и не делает. Просто добавляют новые модули на Kotlin (типа новая Java) и интегрируют в Java-проекты.

Вердикт: новые технологии — не причина переделывать проект. 

Получается — никогда ничего не надо переписывать?

Почти так. По своему опыту можем сказать, что в реальном мире переписывать проект нужно в 1 из 100 случаев.

Главная мысль: переписывание — риск и деньги. Никто не хочет нести дополнительные риски, никто не хочет тратить дополнительные деньги, если можно их не тратить.

В нашей практике переписывались лишь мелкие проекты (до 2 недель работы). В больших системах полная переделка нереальна. Это долго. 

Во-первых, надо код написать. С грамотными процессами! 

Во-вторых, надо протестировать! Взять и нормально проверить, а на это могут уйти недели.

Никто не даст столько денег на все эти манипуляции. И автор знает про нейросети: даже с ними, когда код пишется быстрее, это не работает, так как аспект тестирования всё равно остаётся нерешённым. Это даже с учётом того, что мы вообще не будем смотреть в код от нейросети (что тоже плохо, но сейчас не об этом).

А когда переписывать?

В одном случае. Если проект вообще не работает.

Вот есть код, но не запускается. Причём Вы постарались и приложили силы, чтобы его запустить. И вот если не получилось, а Вы очень старались, тогда официально можно похоронить текущую разработку и создать новый «шедевр».

Плюс, как мы ещё в начале говорили: если можете полностью воссоздать проект за короткое время (до 2 недель) и готовы потратить на это силы и время — дерзайте. 

В остальных случаях переписывать что-то никогда не стоит.

Как-то так.

Нужна помощь?

Не уверены, переписывать или рефакторить? Напишите нам. Проведём Technical Due Diligence и дадим честное заключение: что делать и во сколько обойдётся.

Не дайте программистам развести вас на ненужную переписку, но и не игнорируйте реальные проблемы.