Стартап, новые технологии, современные языки и фреймворки. Всё это так волнительно, когда мы начинаем делать что-то с нуля. И обязательно стараемся выбрать современные, популярные, любимые миллионами технологии для нашего проекта. Но время не останавливает свой неумолимый бег, и вдруг мы оглядываемся назад и видим, что нашему «стартапу» уже 15 с лишних лет. И мир вокруг давно изменился. А у нас в проекте всё тот же Basic/Delphi/Fortran/whatever. И как с этим жить?
Нет, я вовсе не хочу разводить очередной холивар и это далеко не набрасывание на вентилятор. Просто это такая моя личная боль, вести проекты на миллион+ строк кода на устаревших технологиях, в частности на Delphi.
И становится интересно, а сколько же в среднем вообще живет успешный проект. Если посмотреть вокруг, то в принципе проектов с «бородатой историей» довольно много. Это и WinRAR, и Microsoft Office, и AutoCAD, и Photoshop, и 3DSmax и множество других. Причем это проекты для массовой аудитории. А сколько существует различных банковских систем, КИС, CRM и прочих «корпоративных» систем различного уровня. И многие из них писались далеко не в последнюю пятилетку.
Хотелось бы конечно идти в ногу со временем, но мигрировать крупный проект с одного языка на другой, на мой взгляд, тяжёлая задача. Мало того, что пока идет эта миграция и написание нового кода, старый проект должен тоже продолжать работать, жить и развиваться. В новом проекте надо повторить всю логику старого, а она не всегда четкая. В старом проекте много логики может быть построено на библиотеках, которые давно уже не поддерживаются своими разработчиками. В новом проекте этим библиотекам надо искать замену. Если это визуальные компоненты, то с этим еще сложнее, потому что помимо поиска замены нужно еще учитывать, как переписать код работы с этими визуальными компонентами, чтобы новый компонент повторял поведение старого. Конечно, всё решаемо и нет цели повторить работу проекта на 100%, но даже на 50% сделать это очень и очень сложно и в процессе такого переписывания может оказаться, что та платформа/язык, на которую решили переписывать, чем-то не подходит или уже теряет популярность.
Конечно, я в бОльшей степени говорю именно о крупных проектах, со значительным слоем логики. Миллион строк и больше. Т.е. не о мини-сайтах, не о микросервисах, а о таких себе монолитах (пусть даже они и побиты на «компоненты»/«слои» и т.п.).
Хотелось бы узнать мнение здесь присутствующих, сталкивались ли вы с подобными проблемами и как поступали в подобных ситуациях?
Какие решения вы бы посоветовали применить при разработке, чтобы через 10-15 лет не было желания перевести проект на другую платформу?
Спасибо за ответы!
welovelain
Абстрагировать проект от языка разработки. Язык — деталь имплементации, ядро проекта — диаграммы, документация, бизнес-правила. По мере необходимости это имплементируется на нужном языке.
funca
К сожалению так не работает. Описание логики во всех её деталях и подробностях это программный код. На другом языке получится другое описание. Высокоуровневые способы позволяют очертить какие-то грани, быстрее въезжать в проект, но неизбежно теряют информацию. Архитектурные решения также имеют свойство устаревать.
Calc
Зависит от подхода к архитектуре и области.
Если вы сможете рассказать в чем разница учебных задач и производственных, то много сомнений отпадет. При правильном подходе к проектированию вы сможете держать проект «в узде» долгое время. Чаще проблема архитектуры связана с низкими навыками разработчиков и следованием за трендами (хайпом)
Мы в Android разработке в 15м году выбрали правильный путь с полной протоптанной архитектурой еще от майкрософта. До сих пор не поменялся подход, сменили кучу библиотек, парадигм и подходов, но архитектура неизменна. Смена каллбеков на rx, коннекшнов на http клиенты, файловые таблицы на бд всегда происходили без проблем.
Но мобилки это рассказ о локальных архитектурах, сервера куда интереснее, но даже там какой либо jvm сервер будет выбирать между ktor, netty, akka и своим решением. А на PHP подобных только доменная и объектная архитектура по всем правилам, массивы и «новомодные» подходы строжайше запрещены в вопросах архитектуры, но внутри алгоритмических задач полная свобода
funca
В статье автор пишет о проектах на миллионы строк кода и историей развития в десять лет и более. Сюда весь андроид только успевает вписаться. Возьмётесь его повторить, имея лишь документацию? С уменьшением масштабов все становится проще.
alan008 Автор
Не миллионы, а 1-2 миллиона строк — это обычный объем для системы уровня КИС. У нас это система документооборота и собственный текстовый редактор а-ля Ворд, но специализированный под наши внутренние задачи.