Каждый владелец продукта слышал: “Надо всё переписывать”. Но действительно ли это оправдано?

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

Слушайте команду

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

Выясняем причину

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

Возможные причины

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

Библиотека устарела? Обнови. Версия языка старая? Подними. Да, будут проблемы — иди и исправляй. Переписывать всё из-за этого? Ага, конечно.

Пример: переезд с Node.js 8 до 18. Программист не смог подключить Firebase (нужна версия 14+), всё сломалось, он сказал “переписывать”. За пару часов я обновил несовместимые библиотеки — всё заработало.

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

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

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

По опыту — беда в процессах. Как фича попадает в прод? Тестируют ли? Кто проверяет код? Кто оценивает задачи?

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

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

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

Может хватить внедрения тестирования — не мануального, а программного: unit-тесты, автотесты. Да, цикл разработки увеличится, но качество вырастет кратно.

Если не помогло — смотрите предыдущий пункт про процессы.

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

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

Пользователи жалуются на скорость? Сервер падает? Все работает медленно?

Часто решается оптимизацией: кеш, оптимизация запросов к БД, увеличение мощности. Но иногда проект написан криво из-за отсутствия контроля.

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

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

Итог

Устарели плагины/библиотеки? Обновите зависимости.

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

Фичи ломают проект? Внедрите тесты → проверьте процессы.

Тормозит? Оптимизируйте узкие места.

Новые технологии? НЕ причина переделывать проект.

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

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

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

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