PHP ломается не в синтаксисе, а в мелких решениях, которые потом дороже переписывать

PHP ломается не в синтаксисе, а в мелких решениях, которые потом дороже переписывать

За неделю в репах чаще всего видно одно и то же: код работает, но живёт на случайностях. В PHP это обычно вылезает в трёх местах:
— смешали форматирование, доменную логику и запросы к БД в одном классе;
— начали передавать массивы вместо объектов и потеряли контракт;
— не проверили типы на границе входа, а потом ловят странные null и пустые строки.

Есть наблюдение которое стоит проверить: если метод нельзя назвать без слова «process», «handle» или «do», в нём, скорее всего, слишком много ответственности. Разделяйте чтение данных, преобразование и запись. Тогда тесты становятся короче, а баги — локальнее.

Для типичных PHP-проектов полезны простые правила:
— вход валидируется сразу, на краю системы;
— в бизнес-слое работают объекты, а не сырые массивы;
— наружу отдают DTO или ресурс, а не весь внутренний state;
— исключения не глотаются, а переводятся в понятные коды и сообщения.

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

Держите PHP-код скучным на поверхности и строгим внутри: меньше магии, больше явных контрактов, и поддержка перестаёт быть лотереей.