Pull to refresh

Об устаревании кода и жизненном цикле ПО

Project management *Product Management *


Стартап, новые технологии, современные языки и фреймворки. Всё это так волнительно, когда мы начинаем делать что-то с нуля. И обязательно стараемся выбрать современные, популярные, любимые миллионами технологии для нашего проекта. Но время не останавливает свой неумолимый бег, и вдруг мы оглядываемся назад и видим, что нашему «стартапу» уже 15 с лишних лет. И мир вокруг давно изменился. А у нас в проекте всё тот же Basic/Delphi/Fortran/whatever. И как с этим жить?

Нет, я вовсе не хочу разводить очередной холивар и это далеко не набрасывание на вентилятор. Просто это такая моя личная боль, вести проекты на миллион+ строк кода на устаревших технологиях, в частности на Delphi.

И становится интересно, а сколько же в среднем вообще живет успешный проект. Если посмотреть вокруг, то в принципе проектов с «бородатой историей» довольно много. Это и WinRAR, и Microsoft Office, и AutoCAD, и Photoshop, и 3DSmax и множество других. Причем это проекты для массовой аудитории. А сколько существует различных банковских систем, КИС, CRM и прочих «корпоративных» систем различного уровня. И многие из них писались далеко не в последнюю пятилетку.

Хотелось бы конечно идти в ногу со временем, но мигрировать крупный проект с одного языка на другой, на мой взгляд, тяжёлая задача. Мало того, что пока идет эта миграция и написание нового кода, старый проект должен тоже продолжать работать, жить и развиваться. В новом проекте надо повторить всю логику старого, а она не всегда четкая. В старом проекте много логики может быть построено на библиотеках, которые давно уже не поддерживаются своими разработчиками. В новом проекте этим библиотекам надо искать замену. Если это визуальные компоненты, то с этим еще сложнее, потому что помимо поиска замены нужно еще учитывать, как переписать код работы с этими визуальными компонентами, чтобы новый компонент повторял поведение старого. Конечно, всё решаемо и нет цели повторить работу проекта на 100%, но даже на 50% сделать это очень и очень сложно и в процессе такого переписывания может оказаться, что та платформа/язык, на которую решили переписывать, чем-то не подходит или уже теряет популярность.

Конечно, я в бОльшей степени говорю именно о крупных проектах, со значительным слоем логики. Миллион строк и больше. Т.е. не о мини-сайтах, не о микросервисах, а о таких себе монолитах (пусть даже они и побиты на «компоненты»/«слои» и т.п.).

Хотелось бы узнать мнение здесь присутствующих, сталкивались ли вы с подобными проблемами и как поступали в подобных ситуациях?

Какие решения вы бы посоветовали применить при разработке, чтобы через 10-15 лет не было желания перевести проект на другую платформу?

Спасибо за ответы!
Only registered users can participate in poll. Log in, please.
Сколько лет самому старому проекту из тех, над которыми вы сейчас работаете?
2.97% Менее 1 года 10
24.33% От 1 года до 5 лет 82
33.53% От 5 до 10 лет 113
39.17% Более 10 лет 132
337 users voted. 47 users abstained.
Only registered users can participate in poll. Log in, please.
Менялась ли платформа/язык хотя бы одного вашего крупного проекта за время его существования?
57.84% Не менялась 177
29.74% Менялась 1 раз 91
12.42% Менялась более 1 раза 38
306 users voted. 50 users abstained.
Only registered users can participate in poll. Log in, please.
Если платформа менялась, каким образом обеспечивалась «идентичность» нового проекта старому?
21.82% Были чёткие ТЗ 36
78.18% Приходилось глубоко вникать в логику старого кода 129
17.58% Были автотесты 29
12.12% Другое (опишу в комментариях) 20
165 users voted. 137 users abstained.
Only registered users can participate in poll. Log in, please.
Хотели бы вы перевести проект, над которым вы сейчас работаете, на другую платформу/язык?
23.83% Да, по причине устаревания текущей платформы 66
54.87% Нет необходимости 152
18.77% Нет возможности/ресурсов 52
2.53% Иное (опишу в комментариях) 7
277 users voted. 61 users abstained.
Tags:
Hubs:
Total votes 25: ↑23 and ↓2 +21
Views 11K
Comments Comments 209