Надо переписать весь код! Как отличить реальные проблемы от хотелок программистов

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

Метод работает даже если вы совсем ничего не понимаете в программировании и термины "рерайт" и "рефакторинг" для вас означают примерно одно и то же (непредвиденные расходы).

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

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

Вот четыре основных аргумента вашего CTO и команды:

Программа тормозит, иногда падает в пиковые часы, а каждая новая фича тянет за собой шлейф из багов.

Что предпринять. Так как это измеримая и оцифрованная проблематика, то требуйте графики инцидентов и точное количество часов, потраченных на восстановление системы.

Пример. Пять разработчиков тратят 50 часов в неделю на починку того, что сломалось после релизов. При ставке 2500 ₽/час это 500 000 рублей в месяц, или 6 млн. в год. Такую сумму вы тратите просто на поддержание текущего функционала уже сейчас. Сравните любые инвестиции в рефакторинг с получившейся суммой, оцените.

Стало сложно нанимать новых программистов, мало библиотек, появляются дыры в безопасности.

Что предпринять. Да, иногда это действительно критично. Но часто - просто желание попробовать новое. Спросите: "Какая бизнес-задача закроется новым стеком?" Если внятного ответа не будет - отложите.

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

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

Что предпринять. В этом случае стоит потратится и нанять внешний аудит - только он подсветит неочевидные проблемы и даст действительно объективную оценку.

Пример. Одна-две недели работы аудитора за 280 - 300 тысяч рублей спасут от ошибок на миллионы. И это не недоверие к команде, а нормальная практика. Лично я, после случая когда мы чуть не похоронили полгода разработки, без внешнего аудита серьезные решения больше не принимаю.

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

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

Важно отметить, что без чётких критериев финала рефакторинг может длиться вечно.

Решение зависит от того, где вы находитесь.

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

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

Ну и как всегда, каверзный вопрос: какой самый яркий аргумент приводила ваша команда, чтобы уговорить вас на рерайт или рефакторинг?

Делитесь в комментариях:)