> Сейчас к нам в команду пришел программист Symfony и предлагает ввести патерн CQRS и писать в Symfony Style.
> Как лучше разрулить ситуацию?
Всё смешалось, стили, программисты, "патерны" какие-то. Вы пытаетесь решить множество не связанных вопросов по организации разработки хватаясь за разные термины, которые на слуху, но про которые пока имеете смутное представление. Термины из разных областей, к тому же.
Если у вас цель - в первую очередь набраться опыта за счёт проекта, попробовать разное, похоливарить на работе и поэксперименировать - держать в том же духе!
Если цель - сдать проект в разумные сроки и бюджет - пишите так как умеете и знаете, постепенно повышая свой уровень, изучая новые подходы, желательно не на основном проекте, а на досуге, или в не критичных его частях хотя бы. Иначе, с таким рвением, вам придётся весь проект переписывать на новую парадигму / фреймворк / "патерн" (прости фаулер) каждый месяц.
Наймите или выделите кого-то на роль лида, и пусть он определяет что использовать, а что нет. Но не каждый новый приходящий разработчик. При всём уважении к Симфони и не любви в Ларавель.
> лучше декларировать подход и расписать документацию о том как он работает и как в него добавляются новые методы
Проблема в том, что если проект будет жить, всё это много раз поменяется, под новые требования, рефакторинг, фиксы. И документация будет врать. Лучше код писать насколько простым, насколько это возможно. Чтобы глядя на него было несложно разобраться. На эту тему много рассуждений у Р. Мартина и С. Макконнелла.
Я тесты использую, как фиксацию того, как работает код, документацию стараюсь вообще избегать.
Я не очень понял пассаж про нового разработчика покидающего проект, вы сбивчиво излагаете. Вообще код ревью общепринятая практика, чтобы изменения в коде не были сюрпризом для команды.
> код, который тяжело читается, но ведущий к правильной архитектуре.
Если пожертвовать простотой кода, к "правильной" архитектуре это вас точно не приведёт. Чем сложнее понять код, тем больше шансов понять его не правильно, и добавить новый не как следовало бы.
Что значит "правильная архитектура" для начала стоит определить. На самом деле её не бывает, это Грааль. Я бы сказал, что есть подходящая и не подходящая, избыточная для требований проекта и отстающая от них, мешающая развитию. По тому что озвучено, ларавеля, с его общепринятыми подходами, вам должно хватит за глаза надолго. Вот когда перестанет хватать, вы хотя бы будете решать реальную проблему, а не придуманную. И найдёте ту архитектуру, которая подходит лучше изначальной, к новым реалиям.
В таких категориях попробуйте мыслить. Если вместо того чтобы пилить свой маркетплейс (т.е. нужные фичи), вы будете искать Грааль, успех проекту не светит.
Простой
