Добрый вечер. Существует десктопный проект с небольшой web частью, который по ряду причин планируется полностью переносить в веб. Технические требования к проекту практически все известны, т.е. весь требуемый функционал определен. Реализовывать все планируем на php + какой-нибудь фреймворк, опыта реализации крупных проектов на веб технологиях у команды нет, так кое-что по мелочам. Но однозначно делать будем своими силами без привлечения сторонних специалистов. Вопрос заключается в выборе между двумя альтернативами
1. Сделать небольшой проект(работ много) на php + фреймворк(с которым пока никто не работал), затем перейти к реализации крупного
Преимущества:
снижение рисков, т.к. в случае знания технологии, процесс займет меньше времени, к примеру 2 месяц на изучение 10 на разработку
Недостатки:
Потери времени на работы, которые не особо то и нужны(тестовый проект)
2. Сразу начинать делать крупный проект в процессе изучая фреймворк и тонкости языка.
Я бы поговорил с девелоперами, может кто то из них хочет сменить специализацию с десктопной на веб и определился с стеком технологий.
Если вы не хотите менять команду — вам нужны люди хорошо мотивированные на смену специализации. Вот с етих ребят и лепить подкоманду, которая будет заниматься переводом проекта на веб.
Иначе — будет печально или долго. Видел примеры.
Ето все моє личное ИМХО.
Здравствуйте, da17, Вы писали:
D>1. Сделать небольшой проект(работ много) на php + фреймворк(с которым пока никто не работал), затем перейти к реализации крупного D>2. Сразу начинать делать крупный проект в процессе изучая фреймворк и тонкости языка.
лучше п.1 (но не на php)
причина в том, что с большим проектом всё равно потратите время на выработку подхода к разработке. с маленьким проектом не будут давить бизнес-задачи, чистый эксперимент с целью обретения понимания возможностей и ограничений.
Здравствуйте, da17, Вы писали:
D>2. Сразу начинать делать крупный проект в процессе изучая фреймворк и тонкости языка.
Сразу делать проект которым будут пользоваться, тестовые поделки никому не нужны. Тут главное не торопиться и объяснить менеджменту следующее, чтобы получить норм проект в проде, надо написать первую версию веб, ее выкинуть, а потом написать вторую версию.
Плюс по пути еще наверное много будите переписывать, т.к. у команды опыта мало.
Надо грамотно определить каким образом вы будите перетаскивать. Простой функционал или часто используемый и т.д. Я бы разбил части на следющие фактороы: сложность реализации, объем реализации, частота использования.
И план переписывания определил бы исходя из них. Сначала что легкое и небольшое, потом то, что почаще используется. А дальше будет видно.
1. Нанять в штат спеца по ключевой технологии (PHP? o'rly 2017?)
2. Сделать тестовый проект с критически важным функционалом (почитайте про minimal viable product и почему это вертикальный по функционалу срез, а не горизонтальный "ура, у нас задеплоилась формочка с кнопочкой")
3. Если всё ОК, то наращиваем мясо фича за фичей (заодно срежете устаревшее).
Но сначала десять раз подумать, точно ли надо что-то переписывать на другую технологию и что именно станет от этого лучше для бизнес-владельца. Иначе можно найти себя в интересной ситуации когда
1) получаешь по сути сопровождение двух систем одновременно (потому что часть юзеров требует старую систему ибо им там удобнее/привычнее)
2) новая система ничем кроме технологии исполнения не отличается от старой: всё то же унылое г... которым столь же неудобно пользоваться
D>2. Сразу начинать делать крупный проект в процессе изучая фреймворк и тонкости языка.
Есть такой подход — реализовывать архитектурно-значимые требования, создавая «представительный» (реализующий несколько ключевых функций) прототип будущей системы, который «простреливает» весь стек, применяемых технологий. Прототип позволит измерить и оценить общесистемные свойства будущего продукта: доступность, быстродействие, надежность, масштабируемость и проч.
