Комментарии 11
Совет 1: Тестирование прошло успешно — срочно выбрасывай готовые решения и пиши подходящую архитектуру.
Это вы серьезно или имеет место сарказм? А то я что-то теряюсь.
Это вы серьезно или имеет место сарказм? А то я что-то теряюсь.Вот, я тоже не понял.
Готовые решения — типа того же сверх-популярного WP — имеют то преимущество, что по ним всегда можно найти информацию. Если у тебя есть проблема — скорее всего, с ней уже кто-то сталкивался, это уже где-то обсуждалось, что-то предлагалось и т.д. Вплоть до того, что эта проблема может быть (и, очень вероятно так) уже кем-то давно решена. Нужно лишь ознакомиться с этим решением и его использовать.
А чтобы 100500 плагинов не конфликтовали — не нужно набирать такую их армию, если не понимаешь (и / или не хочешь / не можешь понять) как они работают. Ну, в крайнем случае, свой плагин можно написать. В чём проблема-то? В разводе заказчика на разработку «с нуля» по соответствующим расценкам?
На хабре сезон статей "менеджмент пожадничал выбрасывать MVP/прототип"
Начинать с микросервисов — оверкилл, особенно с 1 разработчиком
Так что совет как-то наполовину вредный
Начинать с них — да. А вот сразу делать проект максимально готовый к переходу на них — хорошая идея. При том и вордпресс может быть частью такой архитектуры, пускай не микро, но сервисом
istio — что то такое обещает.
Но на самом деле до всяких микросервисов, надо формализовать бизнес процессы и уже их растаскивать по модулям и сервисам или дробить до микросервисов.
Мне вот кажется проблема у Вас не в том что какое-то «не такое» решение выбрали изначально (оно ведь работало!), а в том что проморгали момент когда надо было перейти от «мы ж стартап, фигак в прод и ладно» к «мы ж энтерпрайз». Причём на этапе перехода надо понимать что таки нет — ещё не энтерпрайз.
Я не прав?
ИМХО с микросервисами на ранних стадиях (проверка гипотез ценности и роста стартапа) огребли бы то же самое плюс проблемы с деплоем, мониторингом, консистентностью, траблшутингом межсервисного взаимодействия и e2e тестированием. Я не против микросервисов, но в условиях аврала, неопределенности и бардака в процессах (судя по описанным вами остальным пунктам) они бы вас потопили.
Какие там плагины будет конфликтовать и кто запрещает писать документацию. Сам Yii прекрасно документирован, не разу не видел на сайтах Yii или какой либо cms призыва не писать документацию.
Так может не надо на зеркало пенять, коли… сами знаете что
1. Выбираем любую готовую CMS с большим комьюнити
2. Запрещайте документировать что бы то ни было кроме того, что внесли сами
3. Зовите Гуру
4. Ваш проект должен состоять из одной зоны ответственности в том числе менеджмента. Если компания нанимает «менеджера» значит не доверяет программисту, тут нужно начинать решать проблему с ее корня. Если программист занимается всем, то пусть занимается всем, что касается программирования, по крайней мере он самостоятельно лучше распределит задачи и выставит приоритеты, а если нет то проблема в программисте, значит он не годится для этой работы. Другой вопрос, что такой спец стоит дорого, иногда слишком, но вы ведь зовете Гуру.
5. Если программист сам отчитывается перед бизнесом, то пятый пункт отпадает.
6. Снова недоверие между руководством и исполнителем и неспособность прозрачно отобразить процесс разработки.
Корневая проблема в том, что бизнес видит в программисте источник расходов. Если он будет видеть в нем перспективу и возможность, то все будет иначе. А для этого нужно сделать процесс разработки прозрачным и понятным, нужно снизить риски бизнеса переложив эти риски на программиста, конечно при условии, что это увеличит гонорар в случае успешного достижения результатов (например, пока сайт лежит программист не зарабатывает).
6 способов угодить в ад готовых решений и спустить миллион-другой