Есть проект на ZF1, который до этого момента не перевели на более последнюю версию. Для заказчика важно что бы проект работал - и программисты выполняли его задачи по развитию проекта. Т.е. выполняем задачи, проект улучшается, клиентам лучше/удобнее пользоваться, приходят новые клиенты и приносят доход, компания живет и все как бы хорошо и должно так быть. Но, с точки зрения программистов, ZF1 - не совсем то что сейчас должно быть внутри проекта. Т.к. работать со старым фреймворком это как минимум деградация программистов, и как максимум когда то закончится поддержка ZF1. Задача: перейти на более свежий фрейм. Проблема: Полностью направить программистов на переписку проекта на новый фрейм нельзя, т.к. будет отставание от конкурентов. Как быть?
Взять кредит, работать в убыток. Рассчитывать на более долгосрочный период. Тут экономист должен посчитать. Больше всего это проблема с безопасностью, не знаю сколько ещё для ZF1 будут выпускать заплатки. --- Добавлено --- Ещё попробуйте нанять или переквалифицироваться на yii2, symfony3, возможно это ускорит разработку и сэкономит время. Что за проект? Не обязательно ссылку, а описание чем заниматься
Если особых сложностей в поддержке и развитии существующего проекта на ZF1 не испытываете, то особого смысла переписывать на что-то новое только потому, что это модно не стоит. Если проект большой, то переписыванием, имеется немалая вероятность сделать на порядки хуже и с большим количеством ошибок, прострелив себе обе ноги. Если есть непреодолимое желание таки переписать, то стоит начать это делать маленькими порциями (отдельными сервисами). Кстати, не всегда имеет смысл переписывать под корень, состоявшиеся подсистемы можно и оставить. Сам работал с проектами, где использовался ZF1 на старом функционале и YII2 на новом, все вполне нормально уживается, и переписывать старое никто не собирается, т-к работает все отлично и не доставляет проблем. Имеется еще один проект, с очень сложной бизнес логикой, исключительно на ZF1, которому уже 5 лет, и чтобы переписать его, нужно как минимум год времени всего департамента разработки и аналитического отдела. Естественно, никто в здравом уме переписывать его не будет, т-к нет острой необходимости. Настоятельно рекомендую ознакомиться со следующим материалом
ZendFramework 1 не интересен специалистам. За эти годы очень сильно изменился сам язык PHP. Вообще с PHP 7 дружит только ZF 3. А долгосрочно привязываться к проекту, в котором не получишь профессионального развития, значит ставить на себе крест. Ваш проект движется к катастрофе, потому что никто не начинает изучать ZF 1. Через некоторое время, вы не сможете привлечь новых кадров, кроме новичков, которых интересует только лишь возможность попробовать что-то взрослое. Мой совет - нанять специалистов, которые уже умеют ZF 3, и портировать по чуть-чуть, после чего в определенный момент организовать апгрейд продукта. Прежние специалисты в это время продолжат заниматься поддержкой.
наем дополнительный это дополнительные ресурсы. скорее всего команда прекрасно понимает преимущества новых версий и владеет ими. пускай разработка на новой базе будет частичной мотивацией: определите необходимый минимум задач по развитию который требует бизнес, по завершению задач переключайте команду на ликвидацию технического долга: портированию на новый zf. если ведется разработка новых модулей: сразу ведите разработку на базе новых версий. вполне вероятно что при таком подходе еще и проект на микросервисную архитектуру перенести удастся если ревлизовывать новые модули в рамках отдельных микросервисов.
микросервисы это не то, что стоит затевать, если ты не в гугле. но разбивать хоть на какие-то куски, работающие отдельно несомненно нужно.
Не согласен. Здесь безусловно есть привязка к масштабу продукта, но если проект позволяет выделять относительно независимые модули взаимодействующие с ядром и между собой по API, то ощутим реальный профит от архитектуры. Участвуя в разработке как минимум двух продуктов на пыхе с такой структурой, могу совершенно точно назвать такие преимущества как: 1. Безопасность. Тут всё: разработка, деплой, защита данных и проч. Нет речи о том что все это нельзя реализовать на другой архитектуре, но на микросервисах реально проще. 2. Масштабирование. Здесь всё понятно. 3. Простота и скорость развития/разработки аналогично пункту 1.