Это, кстати, частый вопрос, который бизнес всегда воспринимает “в штыки”. От слова “рефакторинг” предпринимателя бросает в дрожь. А когда речь заходит о полной модернизации … Что?! Заново платить за то, за что я уже заплатил?! Что за бред?!

Да. Платить. И вот почему:

👍10 лет назад язык программирования (в нашем случае) был версии 5.5, а сейчас — 8.2. Язык ОЧЕНЬ существенно поменялся. Найти специалистов, хорошо владеющих сильно устаревшей версией языка так же трудно, как, скажем, найти опытную прядильщицу, владеющую ручным веретеном.

👍Даже если найдем — стоить такой специалист будет баснословных денег. Если, конечно он не дурак.

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

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

👍Очень часто старые продукты плохо документированы и написаны очень путанно. В силу того, что писали их несколько поколений программистов, код в результате похож на “письмо из Простоквашино”. Работа с таким кодом похожа на разминирование бомбы — когда не уверен до конца, что именно произойдет, если изменить строчку кода.

👍Вопросы безопасности. В старых языках старые “дыры”, которые могут использовать злоумышленники. Бизнес в опасности.

Выводы?

Выделяйте своим разработчикам время на “рефакторинг” даже на относительно свежем проекте — такое “техобслуживание” по чуть-чуть (до 20-25% от времени разработки) способно сохранить высокие темпы TTM (Time to market) и продлить сроки жизни проекта.

Закладывайте в финмодель бизнеса, что примерно через 5-7 лет проект часто придется переписать полностью. С нуля. И да — вложив бОльший бюджет, чем в первый раз. Потому, что за 7 лет продукт обрастает новыми функциями.