Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 21
Исправленное заключение:
Laravel — отличный фреймворк для быстрого старта. Он не запрещает хорошую архитектуру, остальное зависит от разработчика.
P.S. Laravel поэтому и стал популярными, что не выносит голову "какой же я сервис делаю Domain или Application?".
Как думаете много разработчиков на старте хотят забивать себе голову этими материями?
Не стоит "заморачиваться" и менять/усложнять базовые правила выбранного фреймворка:
Когда у вас простой проект (кол-во контроллеров и моделей, условно!, 8-10 штук),
Когда проект не собирается развиваться и усложняться (сайт-визитка, лендинг, блог и тп).
А следует задуматься над архитектура, когда проект:
Имеет сложную логику (содержит десятки модулей),
Планируется долгосрочная поддержка и развитие функционала.
Если бизнесу пофиг на будущее, то можно делать как побыстрее, срубить бабло и уволиться. щутка :)))
Прошу прощения, что вопросом на вопрос, но как думаете, много разработчиков спустя год, осозновая, что у них получилось legacy которое нужно переписать, рады этому?))
Я на самом деле думаю, что чем больше опыта, чем больше желания "забивать себе голову этими материям", но конечно, нужно всегда балансировать между скоростью и качеством. Правда меньше всего хочется жертвовать при этом архитектурой.
Если не стоит бизнес цель всё переписать красиво с одной стороны, а с другой стороны нужно, чтобы большой проект работал и развивался, то вам понадобится дополнительный уровень профессионализма на ларе, чтобы писать качественный код.
И да вы пишите о высоких материях, а в Request проверка:
'required|email|unique:users', // в одну строку словно из викторианской эпохи
Разделите строку на массив построчный и ревью правок человеку легче будет делать при добавлении или изменении 1 условия.
Переходя на Symfony, его удивят незнакомые правила <...> Разделение кода по бандлам
ну вот еще. это копролиты, бандлы давно уже (с 5 версии?) не рекомендуются для организации кода.
не позорьтесь
Имхо. Самая большая ловушка в ларавел - люди которые пытаются написать собственную документацию для ларавел, когда готовая уже есть и насадить её всем вообще. Прикол лары именно в том что для большинства проектов достаточно именно того что написано в доке, не больше. А "лучшие практики", особенно если они только на словах, это грабли разбросанные по полу. У каждого эти практики свои, каждый берет всё кусками и нет ничего общего. Выбирая между тем чтобы все было красиво, быстро и субъективно правильно и тем чтобы было по доке которая всегда доступна я бы выбрал второе. При этом да, по сути всё написано по делу, особенно в ларе бесят модели с сериализацией которые могут в некоторых случаях спотыкаться на ровном месте.
/Имхо
Минусом Laravel можно считать невозможность тестировать все компоненты в отдельности.
Laravel будет популярным до сих пор, пока есть бизнес. Бизнесу (в основном малому и среднему) нужно быстрее и дешевле. Laravel обеспечивает быструю разработку своими заготовками.
Поэтому в некоторых проектах это отличное решение, где нет необходимости использовать более сложные технологии.
Из статьи можно понять, что автор руководствуется какими-то четкими правилам связанными с чистой архитектурой. На самом деле всё зависит от конкретной ситуации. Иногда не стоит захламлять код многими слоями абстракций. Особенно, если проект небольшой.
А при написании статьи и этого кода у вас, случайно, не возникло вопросов про троллейбусы и хлеб?
Да, Laravel содержит изначально архитектурные проблемы. Некоторые из них действительно решаются переписыванием куска (процесс этот называется: "берём Laravel и избавляемся от Laravel"), некоторые не решаются в принципе никак (например какую-нибудь кооперативную многозадачность в Laravel не впилить из-за глобального состояния Application, как ни старайся).
Но смысл не в этом же? Laravel хорош тем, что:
Стандартная структура приложения понижает порог входа
Намеренное использование сомнительных или плохих практик в разы повышает прототипирование (и снижает порог входа)
Использование PHP 5 подходов (плюс отсутствие типизации) так же снижает порог входа
Документация из пары десятков страниц полностью описывает вообще всё что "можно и нужно" и снижает порог входа
ххх .... снижает порог входа
Т.е. вы жертвуете скоростью работы приложения, качеством кода, тайп-сейфети и прочим ради повышения производительности на старте и снижением порога входа (в том числе порога входа в готовое приложение, требуется меньше всего изучать, т.к. вся инфра - стандартная).
Более того, сам Laravel не предоставляет никаких инструментов, позволяющих грамотно разрулить все эти проблемы и ограничения, что потребует писать всё это (инфраструктурный код, за который как бы фреймворки и отвечают) фактически с нуля. Получается, как только возникает потребность сделать всё по-нормальному, избавившись от Laravel, то вы избавляетесь от всех преимуществ фреймворка и пишете код с нуля.
Имхо, в Laravel НЕ НАДО писать хороший код. Следует пользоваться стандартными практиками (Laraway, например). Это в каком-нибудь Symfony разрезание слоёв - стандартная практика, а в Laravel преимущество - примитивизм, понятность кода, коробочные решения и простота. Избавляясь от преимуществ Laravel в итоге получаешь только недостатки и вопрос "зачем мне Laravel".
P.S. Я намеренно не рассматриваю ситуацию, когда на Laravel написано что-то крупнее MVP, что бывает "по историческим причинам" довольно часто. В такой ситуации, возможно, реализация самописных решений (как в статье) и спасёт на некоторое время... Но это не точно. Проще, по-моему, поднять рядом Symfony и начать перетаскивать всё туда, где всё описанное вами уже и так или уже есть, или считается вполне стандартной практикой и не вызовет вопросов у новых сотрудников: "А чойто у вас тут происходит, а?".
Laravel не просто «тупая штука для MVP с низим порогом входа». Это гибкий инструмент, склоняющий, но не настаивающий на ненадёжных архитектурных решениях. Внутри как вы правильно написали это просто фреймворк, инфраструктурный код. Симфони тоже — инфраструктура.
Разделение на слои упирается не в фреймворк, а в понимание программистами правил композиции своего кода. В Симфони тоже надо постараться, чтобы слои не оказались перемешаны.
Будет ли качественным код, зависит от качества программистов, а не фреймворка. И бизнесу решать, кого на какой проект нанять. Я вот показал, как улучшить качество кода на Ларавеле, если не стоит бизнес цель всё переписать.
Это гибкий инструмент, склоняющий, но не настаивающий на ненадёжных архитектурных решениях. Внутри как вы правильно написали это просто фреймворк, инфраструктурный код. Симфони тоже — инфраструктура.
Есть огромное отличие между этими двумя фреймворками, которое сильно усложняет или упрощает жизнь в большом проекте.
В первую очередь контейнер в Симфони - декларативный и показывает проблемы на этапе сборки (считай что стат.анализ из коробки). Симфони гарантирует что все 100500 классов актуальны, настроены корректно, не содержат синтаксических ошибок, не продолбались на рефакторинге, не исчезли, не переименовались и прочее. Если в контейнере ошибка в конфигах, то он об этом сообщит сразу же.
За этим вытекают и другие плюшки: Симфони на этапе компиляции, ещё до запуска приложения сообщает о том где есть Deprecated код, какие вызовы методов и классов надо актуализировать, например, чтобы обновиться до новой версии фреймворка, PHP, библиотек и проч.
За этим вытекают и другие плюшки: Например, Симфони может заранее сказать какие ключи в шаблонах не содержат переводов и может автоматически создать их. А если подключить автоматизированные инструменты внешних переводов (тоже из коробки), то ещё и автоматически перевести всё.
За этим вытекают и другие плюшки: .... и т.д.
В отличие от этого в Laravel контейнер исключительно императивный. Чтобы просто узнать что все зависимости прописаны корректно - требуется полный коверейдж всего кода и это можно выяснить только после запуска этих тестов. Никакой гарантии корректности конфигов фреймворк не даёт.
но не настаивающий на ненадёжных архитектурных решениях
Давайте, подкерплю свой тезис, одним простым примером современного кода в Laravel:
Ну вот, недавно в Laravel появились атрибуты. Для их реализации требуется имплементировать интерфейс ContextualAttribute.php. Как вы можете заметить по коду - интерфейс "очень надёжно" гарантирует ровным счётом нифига. Но, чтобы вам не копаться в исходниках, подскажу, что требуется реализация метода resolve() (например Database.php), который импертивно (sic!) из контейнера вытаскивает сервис через сервис-локацию.
Альтернативных вариантов работы с атрибутами Laravel не предоставляет.
Гарантий существования того, что этот
databaseесть в контейнере Laravel не предоставляет.Даже есть он и есть, то в Laravel контейнер мутабельный и наполняется в процессе работы, т.е. нет никакой гарантии того, что этот сервис Х есть в определённый момент времени
А если и есть, то нет никакой гарантии, что он был никем не переопределён.
Фактически, пункты 2, 3 и 4 можно свести с работой с глобальными переменными. Отличий в случае Laravel не особо. И альтернатив (использовать DI вместо глобальных переменных) Laravel не предоставляет.
Мы можем быть супер-охрененными инженерами, но Laravel не только не помогает поддерживать качество ПО, но и чтобы написать качественный и надёжный код - нужно избавляться от Laravel.
А если мы полностью и везде избавляемся от Laravel, чтобы просто написать хороший код, то это уже не Laravel ;)
Так что в итоге, нет, я не согласен. Laravel исключительно для MVP. Да, его можно использовать и для крупных проектов (как и всё что угодно), но там он будет не только не помогать, но и мешаться.
Это чуть другая оптика, но Laravel не защищаю, вы приводите ценные и конкретные фактические наблюдения. Ежедневно сталкиваюсь с тем, как косячно там всё под капотом функционирует.
Laravel может быть "только для MVP", это не отменяет развилку для развивающегося проекта: 1) пишем плохо на Laravel, 2) пишем умно рядом с на Laravel 3) пишем умно без Laravel.
Моя статья исходит из допущения, то уже выбран путь 2. На этот выбор влияет масса в том числе внетехнических условий.
Хотя я понимаю логику предыдущего комментария и даже с ним по большому счёту согласен, статья мне очень понравилась. Да, Ларавель олицетворяет собой подход раннего РНР, "фигак-фигак - и в продакшен". Но если знаешь как правильно, то прогибаться под его идеологию тоже вряд ли будет хорошей идеей. Но главное - разбор кейсов в статье просто замечательный, хоть сейчас в учебник. И, скажем, если не рассматривать её в качестве руководства "как писать на Ларавле", а как аналог знаменитейшей "Symfony versus Flat PHP" - то есть как статью для тех, кто например переходит с Лары на Симфони (или просто хочет расти как разработчик) - то она оказывается супер-полезной, поскольку языком Ларавли говорит о подходах Симфони и чистой архитектуры в целом.
Я работал в большом проекте где построили "архитектурные решения" поверх ларавел. Онбординг нового сотрудника занимает несколько месяцев, потому что новый человек должен изучить по сути новый фреймворк, от ларавел там ничего не остается.
Как уже писали выше, обычно новые правила и подходы никак не документируются. Все по сути держится на том человеке кто это придумал.
Далее происходит печальное - этот человек увольняется и никто больше не следит чтобы соблюдался тот "командный стиль". Каждый начинает добавлять что-то свое, по интуиции, конечно пытаясь повторить практики использующиеся в проекте.
Через несколько лет это превращается в большую сложную кашу, которую уже никто не понимает и не может объяснить. Бизнесу все так же нужно делать быстрые изменения, адаптироваться под рынок, но архитектура проекта этого не позволяет (сильно замедляет).
Все разработчики дружно вздыхают: "на чистом ларавер мы бы сделали это за час!".
Тогда возникает вопрос, как было упомянуто выше, зачем в этом случае использовать Laravel, если ты ничего не используешь из Laravel? Для этого есть более лёгкие решения.
Ох уж эти архитектурные решения. Отдельный самописный фреймворк внутри лары -- это да. Но соглашения есть на каждом проекте. И проверенные шаблоны проектирования, верю, никто клеймить не будет. И разделение кода на слои.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура Laravel: 7 ловушек и практичные решения