Page cover

Laravel

Руководство по использованию Laravel.

Laravel позволяет решить одну задачу несколькими способами. В этом разделе перечислены наши соглашения написания кода на Laravel.

Linting

На всех проектах используется Laravel Pintarrow-up-right.

В PHPStorm можно настроить автоматическое форматирование PHP кода при сохранении Pint - ом:

  1. Отключите встроенное форматирование кода для PHP

  2. Создайте новый File Watcher для Laravel Pint

  3. Используйте следующие настройки

  • Program: $ProjectFileDir$/vendor/bin/pint

  • Arguments: $FileRelativePath$

  • Output paths to refresh: $FileRelativePath$

  • Working directory: $ProjectFileDir$

Контроллеры

Название ресурсных контроллеров должны быть в единственном числе

Названия методов

Старайтесь не выходить за дефолтные CRUD названия методов (index, create, store, show, edit, update и destroy)

Создавайте новый контроллер, если вам нужны другие методы.

Хорошее видео о рефакторинге контроллеров от бывшего мейнтейнера Laravel и создателя Tailwind (язык ENG): Cruddy by designarrow-up-right

Используйте method injection для Request класса и остальных зависимостей

Сначала зависимости из маршрутов, а затем остальные

Маршруты

Используйте новый синтаксис

Адрес маршрута не должен начинаться с /, если только адрес не будет пустой строкой

Параметры должны быть в camelCase

Маршруты должны быть именованными

Маршруты должны начинаться с HTTP метода

Используйте синтаксис массива для Route::middleware()

Request

Используйте методы класса Request вместо магических

Валидация

Старайтесь выносить валидацию в FormRequest arrow-up-rightкласс.

Старайтесь не использовать | как разделитель для правил валидации.

Почему? Синтаксис массива упростит добавление кастомных правил.

Названия кастомных правил должны быть в snake_case стиле

Старайтесь избегать mass assignment

Почему? С фронта к форме можно редактированием html кода добавить поле role с значением admin и оно попадет в бд.

Миграции

Всегда пишите down() метод миграции для возможности отката.

Модели

Всегда начинайте запрос со слова query().

Это помогает IDE понять откуда взят этот метод.

Документируйте модели

На каждом проекте стоит laravel-ide-helperarrow-up-right.

После добавления нового поля миграцией или нового метода в модели добавляйте PHPDoc блок командой.

Выносите захардкоженные значения модели в константы модели

Не используйте старый синтаксис атрибутов

Artisan команды

Имена команд должны быть в kebab-case стиле

Сервисы

Старайтесь выносить логику, которая может быть переиспользована в разных местах приложения в классы сервисы.

Необходимо зависеть от абстракции, а не от реализации

Старайтесь ответить на вопрос: "Может ли текущая реализация быть заменена в будущем?" заранее. Если - да, то необходимо реализовать интерфейс.

Какая от этого польза?

В контексте примера выше. Если в дальнейшем будет необходимо мигрировать с сервиса cloudflare на любой аналог. Нужно будет всего лишь написать новую реализацию интерфейса DNS для аналога, без необходимости изменять код контроллера.

Binding интерфейса к реализации.

Laravel позволяет внедрять зависимости без использования конструктора.

Для классов сервисов старайтесь создавать новые Сервис Провайдерыarrow-up-right. И делать привязку интерфейса к реализации в них.

Какая от этого польза?

Например, необходимо при локальной разработке не отправлять запрос в Cloudlfare. Тогда можно реализовать класс заглушку и подменять их в зависимости от среды разработки.

Коллекции

Оба решения хороши и мы никак не ограничиваем вас в использовании.

Но с помощью коллекций иногда можно получить более элегантное решение, не так ли?

Не злоупотребляйте коллекциями если это вредит читабельности кода!

Конфиги

Не забывайте дублировать новые переменные в файле .env в файл .env.example, скрывая чувствительные данные

Выносите чувствительные данные в конфиги и .env файлы

Полезные ссылки

Last updated