Comments 7
Спасибо всем, кто дочитал до конца!
Я постарался собрать практики, которые реально экономят время и нервы в Laravel-проектах.
Если у вас есть свои лайфхаки по автоматизации — буду рад услышать в комментариях, возможно, смогу дополнить статью.
Спасибо вам за статью, конечно сейчас наберут гуру проверю и скажут что все плохо у вас. А мне понравилось, только вот не могу понять одного, почему вы новым проектам не даёте PHPstan максимальный уровень? Если вы внедряет в существующий проект, тогда имеет место быть, но не для новых же.
Я пробовал, но отказался от такого подхода по причине того, что Laravel имеет много внутренних ошибок и если поставить максимальный level, то PHPStan будет ругаться на ошибки фреймворка.
Я также не использую максимальный level, так как такая строгость может отпугнуть и убить всё желание использовать PHPStan.
Увеличивайте уровень постепенно, но начинайте с 6-7. Меньше уже плохо, так как он начинает закрывать глаза на типизацию.
Попробуйте level = 9 и скажите своё мнение )))
В чём смысл публиковать статьи которые генерирует LLM?
PSR-12 по вашему актуальней чем PER?
PSR-12 — официальный стандарт, а PER — это надстройка над PSR-12 для более строгой проверки. Она расширяет PSR-12 дополнительными правилами для более строгого и единообразного стиля кода (например, обязательное использование declare(strict_types=1), строгие пробелы, порядок импортов и т.п.).
Я считаю, что эти 2 подхода актуальны, но всё зависит от области применения:
Для проектов с открытым кодом, фреймворков, библиотек — PSR-12.
Для внутренних корпоративных проектов, где нужна дисциплина и единый стиль — можно добавить PER поверх PSR-12.
P.S.
Как я писал ранее, я не рекомендую внедрять максимальную строгость на старые проекты, так как это может сильно нагрузить разработчиков и сократить продуктивность.
Проверки и тесты лучше внедрять постепенно!
Автоматизация Laravel: как сделать процесс разработки быстрым и надежным