Когда пора переписывать проект с нуля, а когда рефакторить: гайд для владельца продукта

Наверное, каждый владелец продукта хоть раз слышал фразу: "Надо всё переписывать". Но действительно ли это оправдано или можно как-то потерпеть?

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

Причём реанимация проекта часто происходит не за счёт кода, а совсем иных вещей… но об этом немного позже.

Сойдет за обложку.

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

Главное — понять, почему надо "всё переписывать". Если это прихоть одного человека — можно игнорировать. Если говорит не один, лучше перепроверить — позвать третьего и разобраться. Если так говорят многие, значит, проблема реально существует. Но поможет ли переписывание?

А теперь пробежимся по возможным вариантам возмущениям команды.

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

Был опыт переезда проекта с Node.js версии 8 до версии 18 пару лет назад. Проект хорошо работал, и всех всё устраивало. Позже пришёл программист, который не смог подключить библиотеку Firebase для рассылки push-уведомлений, ибо там требовалась минимум 14-я версия Node.js. Естественно, за час у него не получилось просто "поднять" версию в проекте — всё сломалось, и он объявил, что надо "всё переписывать". Ну ничего, я подключился и всё сам сделал за пару часов: прошёлся по всем плагинам/библиотекам и обновил несовместимые.

Вердикт: переписывать не нужно. Достаточно провести точечное обновление плагинов и библиотек.

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

В маленьких проектах фича выкатывается за 2–3 дня. Бывает даже за один. В больших этот цикл возрастает до недель. Опять же, всё зависит от фичи, но что-то маленькое за 4–5 дней доедет до релиза, а на что-то покрупнее и 2 недели придётся подождать.

Если же фича в вашем проекте выкатывается за половину потенциального срока копии текущего проекта — это ненормально. Проблема 100% есть, но в коде ли?

Возможно и в коде, но по опыту скажу, что беда в процессах.

Как вообще фича выкатывается в боевую среду? Тестируют ли её? Кто тестирует? Как человек узнаёт, что пора тестировать? Да и вообще, когда программист код куда-то отправляет/выкладывает, его кто-то более опытный смотрит? Ну а если ещё глубже копать — кто оценивает время на задачу? Кто проверяет это время?

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

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

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

Менее плохо, чем прошлый вариант, но с двойным дном.

С одной стороны, может хватить внедрения тестирования. Причём я не про мануальное (ручное, оно уже должно быть), а программное: unit-тесты, автоматизированное регрессионное тестирование. Иногда это может помочь. Да, цикл разработки увеличится, и срок "выкатывания" фичи в боевую среду вырастет. Но это кратно повысит качество кода и поможет выстроить более качественные процессы внутри команды.

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

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

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

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

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

Вердикт: сначала выясните проблемные участки и оптимизируйте кешем. Если не помогает — переписывайте узкие места.

Устарела кодовая база? Обновите зависимости, не переписывайте.

Сложно добавлять функционал? Оптимизируйте бизнес-процессы в разработке.

Каждая фича всё ломает? Внедрите тесты → если не помогло, смотрите прошлый пункт.

Проект тормозит? Оптимизируйте → если не помогло, перепишите узкие места (но не весь проект).

Хотим новые технологии? Это НЕ причина для переписывания.

Главное правило: переписывание — это всегда риск и большие деньги. На моей практике переписывались лишь мелкие проекты, где цена переделки не более 2 недель на весь проект. А в больших системах (реально больших, не интернет-магазин или CRM-система) полная переделка — это что-то около… нереального, потому что никто не даст столько денег на разработку.

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