Программисты часто упрямы. Мы гордимся тем, что умеем абстрагироваться, строить свои слои и границы, моделировать сложные бизнес-процессы. Мы читаем книги, впитываем принципы SOLID, обсуждаем DDD на митапах и конференциях. Мы хотим, чтобы наш код жил дольше, чем фреймворк, на котором он написан.
Это выглядит как зрелость, но в действительности это просто страх зависимости. Мы боимся, что инструмент сделает нас менее универсальными. Что мы «завязнем» в платформе. Что не сможем мигрировать. Что нас будут называть «разработчик на XXX», а не просто «разработчик».
Но это — иллюзия.
Брюс Ли говорил: не бойся того, кто знает тысячу приёмов. Бойся того, кто отточил один приём тысячу раз.
Когда ты добавляешь фреймворк в composer.json, ты подписываешь негласный договор. Ты не просто берёшь инструмент — ты
принимаешь архитектурный стиль, соглашения, ритм разработки. Ты говоришь: «Эта платформа решает мои задачи. Я готов
работать по её правилам».
Но что часто делают разработчики после этого? Начинаем сопротивляться. Гнём платформу под себя. Строим абстракции поверх уже готовых механизмов. Добавляем лишние слои. Изобретаем велосипед, чтобы чувствовать контроль.
Вот конкретный случай. В Laravel у нас есть Eloquent ORM. У модели User есть уже готовый интерфейс к данным:
User::query(), User::find(), User::where(...). Эти методы уже инкапсулируют доступ к данным.
Но некоторым разработчикам кажется, что этого недостаточно. Они строят поверх этого UserRepositoryInterface,
EloquentUserRepository, CachedUserRepository, внедряют их в сервисы, пишут фабрики. Почему?
Потому что где-то они прочитали, что "работа с базой данных должна быть скрыта за интерфейсом". Но этот принцип вырван из контекста. Он применим в условиях, где инфраструктура сложна и разнообразна: файловые БД, распределённые хранилища, переключаемые бэкенды. Laravel же, как и в большинстве современных фреймворков, сам фреймворк уже является мощным адаптером.
В результате мы не получаем ни гибкости, ни производительности. Только архитектурный шум.
Принять фреймворк — значит использовать его силу, выразительность и экосистему. Это не поражение. Это зрелость. Играй по правилам — и ты удивишься, насколько всё может быть просто.
В один момент тебе покажется, что ты стал умнее фреймворков. Что можешь выжать максимум из каждого. Взять миграции из CakePHP, FormRequest из Laravel, консольные команды из Symfony, что-нибудь из Yii. Ведь ты же архитектор. Ты знаешь, что делаешь. Правда?
Нет. Ты просто устроил себе проводной ад.
С виду это кажется гибкостью. Мол, ты не привязываешься ни к чему. Но на практике — ты просто собрал чемодан, полный переходников. Всё греется, шумит, не влезает в рюкзак, требует постоянной настройки.
Любой фреймворк — это не просто набор библиотек. Это договор на стиль разработки. Он решает проблемы целиком. У него есть ритм, философия, экосистема. Когда ты от него откусываешь кусками, это уже не Symfony, не Laravel и не Yii. Это что-то, что не будет полноценно поддерживаться ни сообществом, ни документацией, ни будущими разработчиками.
Важно понимать, что не все разработчики сразу открыты к использованию новых инструментов или технологий. Навязывание определённого фреймворка или подхода без учёта мнения и опыта команды часто вызывает сопротивление, снижение мотивации и даже саботаж.
Если вы столкнулись с сопротивлением со стороны вашей команды, необходимо провести открытый и честный разговор, чтобы по возможности уладить их опасения. Поиск совета у опытного профессионала может быть полезным для нахождения взаимоприемлемого решения.
Но если ты чувствуешь, что инструмент тебе не близок, — это нормально. Не пытайся "переделать" его под себя. Не стоит быть как наивная девушка, надеющаяся, что парень изменится — и всё станет как в сказке. Так не работает. Это не значит, что ты плохой разработчик. И не значит, что инструмент плохой. Просто вы не совпали.
Слишком часто мы боимся это признать — и начинаем "улучшать". Переписывать, извращать, подгонять. Вместо этого — просто не используй его вовсе. Выбирай те инструменты, которые соответствуют твоей философии и задачам. Не строй CQRS там, где у тебя обычный CRUD. Не впихивай микросервисы в монолит. Не применяй DDD, если у тебя нет сложной предметной области.
Ты либо принимаешь инструмент целиком и используешь его силу. Либо честно отказываешься — и идёшь другим путём. Половинчатое принятие — не компромисс, а архитектурное лицемерие. Борьба с инструментом — всегда путь в хаос.