[Управление продуктом, Управление проектами] Об устаревании кода и жизненном цикле ПО
Автор
Сообщение
news_bot ®
Стаж: 6 лет 7 месяцев
Сообщений: 27286
Стартап, новые технологии, современные языки и фреймворки. Всё это так волнительно, когда мы начинаем делать что-то с нуля. И обязательно стараемся выбрать современные, популярные, любимые миллионами технологии для нашего проекта. Но время не останавливает свой неумолимый бег, и вдруг мы оглядываемся назад и видим, что нашему «стартапу» уже 15 с лишних лет. И мир вокруг давно изменился. А у нас в проекте всё тот же Basic/Delphi/Fortran/whatever. И как с этим жить?
Нет, я вовсе не хочу разводить очередной холивар и это далеко не набрасывание на вентилятор. Просто это такая моя личная боль, вести проекты на миллион+ строк кода на устаревших технологиях, в частности на Delphi.
И становится интересно, а сколько же в среднем вообще живет успешный проект. Если посмотреть вокруг, то в принципе проектов с «бородатой историей» довольно много. Это и WinRAR, и Microsoft Office, и AutoCAD, и Photoshop, и 3DSmax и множество других. Причем это проекты для массовой аудитории. А сколько существует различных банковских систем, КИС, CRM и прочих «корпоративных» систем различного уровня. И многие из них писались далеко не в последнюю пятилетку.
Хотелось бы конечно идти в ногу со временем, но мигрировать крупный проект с одного языка на другой, на мой взгляд, тяжёлая задача. Мало того, что пока идет эта миграция и написание нового кода, старый проект должен тоже продолжать работать, жить и развиваться. В новом проекте надо повторить всю логику старого, а она не всегда четкая. В старом проекте много логики может быть построено на библиотеках, которые давно уже не поддерживаются своими разработчиками. В новом проекте этим библиотекам надо искать замену. Если это визуальные компоненты, то с этим еще сложнее, потому что помимо поиска замены нужно еще учитывать, как переписать код работы с этими визуальными компонентами, чтобы новый компонент повторял поведение старого. Конечно, всё решаемо и нет цели повторить работу проекта на 100%, но даже на 50% сделать это очень и очень сложно и в процессе такого переписывания может оказаться, что та платформа/язык, на которую решили переписывать, чем-то не подходит или уже теряет популярность.
Конечно, я в бОльшей степени говорю именно о крупных проектах, со значительным слоем логики. Миллион строк и больше. Т.е. не о мини-сайтах, не о микросервисах, а о таких себе монолитах (пусть даже они и побиты на «компоненты»/«слои» и т.п.).
Хотелось бы узнать мнение здесь присутствующих, сталкивались ли вы с подобными проблемами и как поступали в подобных ситуациях?
Какие решения вы бы посоветовали применить при разработке, чтобы через 10-15 лет не было желания перевести проект на другую платформу?
Спасибо за ответы!
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление продуктом, Управление разработкой] 22 сентября, Онлайн-митап Product Engineering Meetup #2: Культура разработки
- [Карьера в IT-индустрии, Управление персоналом, Управление проектами, Управление e-commerce] Пошаговый план для директора по качеству клиентского обслуживания, чтобы его не уволили в этом году (перевод)
- [Информационная безопасность, Совершенный код, Управление продуктом, Софт] Строим безопасную разработку в ритейлере. Опыт одного большого проекта
- [Карьера в IT-индустрии, IT-эмиграция, Управление продуктом] [Личный опыт] Переехать в Штаты и устроиться в компанию мечты: советы от продакт-менеджера
- [Управление продуктом] Для чего и как проводить исследование клиентов?
- [Карьера в IT-индустрии, Развитие стартапа, Управление продуктом, Управление разработкой] Составление требований к разработке фичей: Курс Создание программного продукта и управление его развитием
- [Data Mining, Big Data, Визуализация данных, Управление проектами, Управление продуктом] Анализ расписания и загрузки в Tableau
- [CRM-системы, Управление проектами] Где клиника теряет деньги на каждом этапе плана лечения (и где воруют)
- [Управление проектами, Управление продуктом] Пользовательские истории – это не требования
- [Управление проектами, Управление продуктом] Архитектура Пизанской башни
Теги для поиска: #_upravlenie_produktom (Управление продуктом), #_upravlenie_proektami (Управление проектами), #_zhizn_bol (Жизнь боль), #_upravlenie_produktom (
Управление продуктом
), #_upravlenie_proektami (
Управление проектами
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 28-Сен 09:25
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 7 месяцев |
|
 Стартап, новые технологии, современные языки и фреймворки. Всё это так волнительно, когда мы начинаем делать что-то с нуля. И обязательно стараемся выбрать современные, популярные, любимые миллионами технологии для нашего проекта. Но время не останавливает свой неумолимый бег, и вдруг мы оглядываемся назад и видим, что нашему «стартапу» уже 15 с лишних лет. И мир вокруг давно изменился. А у нас в проекте всё тот же Basic/Delphi/Fortran/whatever. И как с этим жить? Нет, я вовсе не хочу разводить очередной холивар и это далеко не набрасывание на вентилятор. Просто это такая моя личная боль, вести проекты на миллион+ строк кода на устаревших технологиях, в частности на Delphi. И становится интересно, а сколько же в среднем вообще живет успешный проект. Если посмотреть вокруг, то в принципе проектов с «бородатой историей» довольно много. Это и WinRAR, и Microsoft Office, и AutoCAD, и Photoshop, и 3DSmax и множество других. Причем это проекты для массовой аудитории. А сколько существует различных банковских систем, КИС, CRM и прочих «корпоративных» систем различного уровня. И многие из них писались далеко не в последнюю пятилетку. Хотелось бы конечно идти в ногу со временем, но мигрировать крупный проект с одного языка на другой, на мой взгляд, тяжёлая задача. Мало того, что пока идет эта миграция и написание нового кода, старый проект должен тоже продолжать работать, жить и развиваться. В новом проекте надо повторить всю логику старого, а она не всегда четкая. В старом проекте много логики может быть построено на библиотеках, которые давно уже не поддерживаются своими разработчиками. В новом проекте этим библиотекам надо искать замену. Если это визуальные компоненты, то с этим еще сложнее, потому что помимо поиска замены нужно еще учитывать, как переписать код работы с этими визуальными компонентами, чтобы новый компонент повторял поведение старого. Конечно, всё решаемо и нет цели повторить работу проекта на 100%, но даже на 50% сделать это очень и очень сложно и в процессе такого переписывания может оказаться, что та платформа/язык, на которую решили переписывать, чем-то не подходит или уже теряет популярность. Конечно, я в бОльшей степени говорю именно о крупных проектах, со значительным слоем логики. Миллион строк и больше. Т.е. не о мини-сайтах, не о микросервисах, а о таких себе монолитах (пусть даже они и побиты на «компоненты»/«слои» и т.п.). Хотелось бы узнать мнение здесь присутствующих, сталкивались ли вы с подобными проблемами и как поступали в подобных ситуациях? Какие решения вы бы посоветовали применить при разработке, чтобы через 10-15 лет не было желания перевести проект на другую платформу? Спасибо за ответы! =========== Источник: habr.com =========== Похожие новости:
Управление продуктом ), #_upravlenie_proektami ( Управление проектами ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 28-Сен 09:25
Часовой пояс: UTC + 5