Сегодня хочу поговорить про одну проблему, с которой я сталкивался сам и вижу её у других PHP-разработчиков - “магия” в коде.
Что я имею в виду? Это когда ты открываешь проект, а там сервисы создаются «сами собой», данные в объект попадают неизвестно откуда, а половина зависимостей подтягивается где-то «под капотом».
Вроде удобно - меньше кода писать. Но вот через пару месяцев ты сам же сидишь и думаешь: «А откуда вообще берётся этот объект? И почему тут такая зависимость?»
🔹 Основная проблема магии - она убивает явность кода. Чем больше скрытых механизмов, тем сложнее поддерживать проект и подключать новых разработчиков.
Примеры из практики:
- Использование глобальных хелперов вместо DI.
- Автоматический вызов методов через __call или __get.
- Массовая магия в Laravel (facades, hidden bindings и т.д.).
🛠 Что можно сделать:
1. Минимизировать скрытые механизмы - лучше написать чуть больше явного кода.
2. Использовать контейнер зависимостей, но регистрировать их явно.
3. Документировать «точки входа» и договориться в команде, где магия допустима, а где нет.
Когда код становится предсказуемым, ты меньше тратишь времени на дебаг, быстрее понимаешь чужие изменения и увереннее двигаешься вперёд.
А как у вас в проектах? Вы за явный код или любите, когда всё работает «само»?
👉 @php_lib
Что я имею в виду? Это когда ты открываешь проект, а там сервисы создаются «сами собой», данные в объект попадают неизвестно откуда, а половина зависимостей подтягивается где-то «под капотом».
Вроде удобно - меньше кода писать. Но вот через пару месяцев ты сам же сидишь и думаешь: «А откуда вообще берётся этот объект? И почему тут такая зависимость?»
🔹 Основная проблема магии - она убивает явность кода. Чем больше скрытых механизмов, тем сложнее поддерживать проект и подключать новых разработчиков.
Примеры из практики:
- Использование глобальных хелперов вместо DI.
- Автоматический вызов методов через __call или __get.
- Массовая магия в Laravel (facades, hidden bindings и т.д.).
🛠 Что можно сделать:
1. Минимизировать скрытые механизмы - лучше написать чуть больше явного кода.
2. Использовать контейнер зависимостей, но регистрировать их явно.
3. Документировать «точки входа» и договориться в команде, где магия допустима, а где нет.
Когда код становится предсказуемым, ты меньше тратишь времени на дебаг, быстрее понимаешь чужие изменения и увереннее двигаешься вперёд.
А как у вас в проектах? Вы за явный код или любите, когда всё работает «само»?
👉 @php_lib