Как вы меняете технологии в долгоиграющем проекте?

Question

[Дмитрий Скрябин]

Есть система управления предприятием, в которой все - биллинг, клиенты, сотрудники, управление сторонними сервисами, прием платежей и т.д. Систему начали разрабатывать более 10 лет назад. Чтобы не отставать от технологий, мы периодически внедряем что-то новое, но старое все равно идет грузом, так как переделать все нереально, но дорабатывать часто приходится и в старом коде. В итоге на бекенде у нас сейчас 2 фреймворка - древний CodeIgniter и не совсем новый Symfony, который оказался не совсем подходящим для нас. На фронтенде смесь обычных страниц + jquery с новым интерфейсом на Angular 1.3. И 3 разных дизайна. Это все работает, и работает более-менее хорошо - есть четкое понимание, где что допилить в случае чего. Но из-за кучи технологий разработка идет медленнее, к тому же некоторые возможности не используются или используются не в полной мере. Хочется все это прибрать, чтобы все было однообразно и по максимуму прозрачно и современно.
У вас есть опыт смены технологий в больших проектах? Расскажите о своем опыте, как вы разгребали такую кучу?

Comments

[Light Air]

Наймите нормального, адекватного ТД/ТМ, он вам всё разрулит и укажет направление.
И кстати правильно пишется Symfony, а не Symphony

[Дмитрий Скрябин]

Light Air: Ага, а еще можно нанять сто нормальных, адекватных программистов, которые все перепишут за месяц и все будет в шоколаде. Зачем вообще спрашивать что-то на Тостере, если можно нанять адекватного сотрудника?

[Light Air]

Дмитрий Скрябин: а я откуда знаю, зачем спрашивать на Тостере? Но раз мой коммент тебя задел, значит проект либо твой, либо ты не заинтересован в его развитии.

[Дмитрий Скрябин]

Light Air: Проект мой, не скрываю и не стесняюсь этого. А также того, что хочу все поменять. Для этого и спрашиваю про опыт других, более компетентных людей.

[Light Air]

Дмитрий Скрябин: так я и не осуждаю, даже и право не имею. Просто советую. Если проект сколько то вывозит, лучше нанять сильного разраба который и тебя по скилу прокачает и проект подтянет. А с учётом того, что проект в любом случае придётся переписывать, т.к. используется CodeIgniter, то это наиболее рациональный вариант.

[Оптимус Пьян]

+1 за микросервисы как OnYourLips самый годный совет в этом случае

[Толстый Лорри]

А у вас самый бестолковый ответ здесь)

[Оптимус Пьян]

Толстый Лорри: Спасибо, нам очень важно было знать ваше мнение

[Толстый Лорри]

Оптимус Пьян: не стоит плагодарности)

[evnuh]

Скажите откровенно, когда было лучше - когда был один codeigniter и jquery или когда codeigniter + symfony и jquery + angular?

[Дмитрий Скрябин]

evnuh: Сложно сказать. Раньше было проще потому, что все было "в лоб", и не было груза за спиной. Да и сервисов (услуг) было меньше. Но были проблемы, например, с проверкой прав доступа - проверяли вручную в контроллерах. Сейчас проще потому, что на Ангуляре новые интерфейсы делать намного проще и быстрее, и некоторые данные не нужно загружать повторно с сервера. Но зато Symfony работает медленнее, чем CodeIgniter (для наших запросов). Еще раньше были свои стили которые часто не покрывали потребности, а сейчас используем Bootstrap.
Все-таки склоняюсь к тому, что сейчас лучше, чем когда был только codeigniter и jquery. Мы попробовали SPA, поняли плюсы и минусы и готовы идти дальше.

Answer 1

[xmoonlight]

1. Выбирается модуль в системе
2. Создаётся его копия на новой системе/технологиях
3. Отлаживается, настраивается, адаптируется для основной.
4. Старый - отключается, новый - включается в продакшн.
5. GOTO 1.

PS: Ни в коем случае не выделяем микросервисы! Это нарушит целостность смежных архитектур внутри системы! Меняем - только функциональными блоками, которые работают по заранее определённой и отлаженной схеме бизнес-процесса.

Comments

[sim3x]

0. Покрываем все тестами

[xmoonlight]

sim3x: нет. это лишнее. п.3 - достаточно.
Если там недостаточно отладили - то это проблема уже требований к проведению тестирования перед переключением в п.3.

[Дмитрий С]

xmoonlight: нет, не лишнее. Если система покрыта тестами, перевести её на новую технологию в разы легче.

[xmoonlight]

Дмитрий С: Слово "отлаживается" - подразумевает все необходимые работы по обеспечению нужного уровня сервиса перед заменой. Таким образом, тестирование (если таковое предполагается) уже включено в этот пункт.
Поэтому, получается, что здесь доп.пункт - лишний.

Answer 2

[dmitriy]

интернет-магазин был написан на joomla, потом cms заменили на codeigniter 1.x, затем на codeigniter 2.x, сейчас планируется перевести на frameworkless.
По сути каждая смена как правило проходила с пулом объемных задач, смена дизайна, реализация админки и т.д.
Создавались новые таблицы, производились миграции старых данных в новую структуру таблиц. Создался список основных страниц и что должно быть, как должно работать, для проверки после миграции. Создавалась новая sitemap настраивались редиректы с старых страниц на новые.

Answer 3

[Draconian]

Можно только добавить, что технологии меняются волевым решением руководителя проекта.
При этом, само собой, у руководителя должно быть представление о том, сколько времени это займет, какие сотрудники насколько будут загружены. Т.е. придется жонглировать реализацией новых функций и перепиской старых.
Либо достигаются договоренности о перерыве в реализации новых функций, пока не будет готов старый функционал.

Пока не будет принято решение о необходимости перехода и составлен какой-никакой план перехода, это всё так и будет тянуться.

Comments

[vjjvr]

Оба оно как, оказывается рядовые разработчики (которые вчерашние джуниоры) лучше разбираются в технологиях, чем руководитель проекта?

[Draconian]

По-моему, я прямо написал, что решение принимает руководитель. Разработчики здесь совсем ни при чем.

Answer 4

[vjjvr]

Важно прописать API для взаимодействия между модулями. Иногда приходится делать прокси-прослойки, для смены технологий по API.

Все остальное просто.
Меняется небольшой модуль.
В частности микросервисы под это подходят.

Answer 5

[Андрей Плетенев]

Для смены технологий необходимы 2 основных ресурса: деньги и время. Причем время тоже пересчитывается в деньги. Для того, чтобы получить эти ресурсы нужно:
1) Четко понять цель, для чего вы это собираетесь делать.

Хочется все это прибрать, чтобы все было однообразно и по максимуму прозрачно и современно.

- это не цель. Разумный человек под нее ресурсы не выделит. Все останется, как есть, пока не выявится другая цель. Примеры валидных целей в данном случае: a) Снизить затраты на развитие продукта b) Снизить затраты на качество (это в случае, когда зоопарк технологий не позволяет поддерживать качество на должном уровне).
2) В зависимости от цели, вам придется сделать прикидочные расчеты: оценить экспертным путем сколько потерь, обусловленных старыми технологиями, вы имеете в расчете на единицу времени (день, неделю, месяц) по сравнению с тем, как если бы это все было уже написано по новому. Потери могут расти со временем. Наложите на шкалу времени - получите график экономии.
3) Посчитайте инвестиции, необходимые на проект замены технологий: проектирование, переписывание, интеграцию, тестирование, документирование, управление, обучение и т.п. Сделайте график проекта, включая необходимое финансирование.
4) Состыкуйте график экономии с даты начала ее получения с графиком денежного потока инвестирования. Приведите анализ рисков для случаев "переделывать" и "оставить как есть". Дальше спонсоры проекта проведут обычный анализ инвестиционной привлекательности проекта и скажут вам стоит ли овчинка выделки.
5) Если денег не дают - изменяете подход к переделке и повторяете итерацию, начиная с п.2.