Скелет PHP-проекта: 5 дней, которые не попадают в счёт

Каждый проект начинается с одной и той же недели: репозиторий, загрузчик конфига, обработчик ошибок, страница входа, миграция для пользователей, три папки, о которых никто не договорился. Скелет PHP-проекта превращает эту неделю в одну команду, и первый тикет про бизнес-правила приходит на четыре дня раньше.

Код: Atomic-Framework-Application, лицензия GPL-3.0-or-later.

Скелет это официальный старт для Atomic Framework, PHP 8.1 или новее, на той же лицензии GPL:

composer create-project globus-studio/atomic-framework-application myapp
cd myapp
cp .env.example .env
php atomic init/key
php -S localhost:8000 -t public

Что скелет PHP-проекта заменяет в первую неделю

Composer подтягивает фреймворк, ORM и автозагрузчик. init/key создаёт ключи шифрования, и это тот шаг, который команды забывают до первого раза, когда сессия отдаёт cookie открытым текстом. Приложение поднимается на localhost:8000 с приветственной страницей, а в репозитории лежит .env.example со списком того, что нужно серверу.

Это день настройки, который не требует старшего разработчика, и именно этот день обычно достаётся самому дорогому человеку в комнате, потому что остальные ещё не знают фреймворк.

Папки говорят, куда что класть

app/ держит контроллеры, модели, middleware и провайдер пользователей. bootstrap/ держит константы, загрузчик конфига и обработку ошибок. config/ держит базу, кеш, почту, аутентификацию и очередь. routes/ разделён на web.php, api.php и cli.php, поэтому команда CLI случайно не становится адресом. public/ это корень сайта с темами и загрузками, database/ держит миграции и сиды, resources/ шаблоны, storage/ логи, кеш и сессии.

Список выглядит скучно, и в этом смысл. Новый разработчик открывает репозиторий и знает, куда положить файл, не спрашивая, а на ревью во вторую неделю уже нет спора о структуре.

Аутентификация приходит рабочим примером

Со скелетом идут три контроллера: посадочная страница, панель под авторизацией и вход с регистрацией и выходом. Dashboard закрыт middleware Authenticate, модель User несёт uuid, email, password и role, провайдер читает пользователей из базы, для таблицы пользователей есть миграция.

Это вертикальный срез, а не заглушка. Клиент входит в первый день и видит закрытую страницу, и разговор о том, работает ли окружение, заканчивается.

Требования записаны

PHP 8.1 с расширениями json, session, mbstring, fileinfo, pdo, pdo_mysql и curl. MySQL или MariaDB для данных, Redis рекомендуется для кеша, очередей, сессий и WebSocket, Composer для зависимостей.

Разговор с хостингом требует этого списка на экране, и он лежит в README, а не в чьей-то памяти. Половина задержек в первом спринте приходит из отсутствующего расширения, а отсутствующее расширение стоит обращения в поддержку и перезапуска выкладки.

Что проверить на старте

Три вещи ломают первый выкладку чаще остальных: .env попал в репозиторий, storage/ закрыт для записи, миграции не прогнаны на сервере. Каждая видна в первые пять минут, если смотреть в правильное место, и каждая стоит часа, если смотреть не туда.

Дальше очередь и расписание. Воркер запускают под supervisor, иначе письма копятся в таблице, и никто этого не замечает до первой жалобы. schedule/run вешают на cron раз в минуту, иначе ночной отчёт не выйдет ни разу.

Чего скелет не решает

Он не выбирает конструктор страниц, CSS-фреймворк и админку. Он не генерирует экраны CRUD, а миграции остаются написанными руками файлами.

Для продукта с твёрдым мнением об интерфейсе это свобода. Для команды, которая ждала генератор, это работа, которая остаётся в оценке, и делать вид, что её нет, значит получить неприятный сюрприз на третьей неделе.

Сколько это стоит

Час на установку и чтение папок против недели, которая больше не появляется в счёте. Вопрос лицензии тот же, что у фреймворка: GPL-3.0-or-later, что подходит клиентскому сайту и требует юридической проверки для закрытого продукта.

Рядом: фреймворк для бизнес-приложений о том, что несёт сам фреймворк, и разработка на PHP о том, как считается объём приложения.