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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.


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

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

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

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

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

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

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

Спасибо за ответы!

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Сколько лет самому старому проекту из тех, над которыми вы сейчас работаете?

  • 1,2%Менее 1 года1
  • 25,3%От 1 года до 5 лет22
  • 31,0%От 5 до 10 лет27
  • 42,5%Более 10 лет37

Менялась ли платформа/язык хотя бы одного вашего крупного проекта за время его существования?

  • 51,2%Не менялась42
  • 34,2%Менялась 1 раз28
  • 14,6%Менялась более 1 раза12

Если платформа менялась, каким образом обеспечивалась «идентичность» нового проекта старому?

  • 19,2%Были чёткие ТЗ10
  • 73,1%Приходилось глубоко вникать в логику старого кода38
  • 15,4%Были автотесты8
  • 13,5%Другое (опишу в комментариях)7

Хотели бы вы перевести проект, над которым вы сейчас работаете, на другую платформу/язык?

  • 23,7%Да, по причине устаревания текущей платформы18
  • 55,3%Нет необходимости42
  • 15,8%Нет возможности/ресурсов12
  • 5,3%Иное (опишу в комментариях)4
Источник: https://habr.com/ru/post/519630/


Интересные статьи

Интересные статьи

Если хочется сделать передачу или хранение данных более надёжными, применив к ним избыточное кодирование, то для этого неплохо подойдёт код Рида-Соломона. Понимаю, что на эту тему написан...
Есть несколько способов добавить водяной знак в Битрикс. Рассмотрим два способа.
Инструменты статического анализа кода ушли далеко вперёд. Это вовсе не те "линтеры", которые активно применялись 20 лет тому назад. Однако многие по-прежнему относятся к ним...
Телефон Брэда разразился знакомой трелью внутриофисного звонка. — Да? – рявкнул он, поднимая трубку. – Чего вам? По меркам Брэда, такая манера общаться по телефону, на самом деле, счит...
Я — большой любитель TypeScript. По возможности я стараюсь использовать этот язык в своих проектах. TypeScript даёт разработчику отчёты об ошибках и проверку типов в JavaScript и TypeScript-коде....