Я Олександр Майстренко, ІТ-директор і викладач PHP-курсів (php-pro, php-base, php-web). Програмую вже майже два десятиліття і близько десяти років викладаю PHP на курсах, люблю чистий код і здоровий скепсис.

Цей канал — для моїх студентів і всіх, хто працює з PHP, вчиться чи просто не вилазить із PhpStorm.

Тут буде все по темі PHP

Чому канал називається саме так?

UPD:
В коментарях під цим постом можна писати запити на теми, що вас цікавлять

Перелік хештегів для зручного пошуку постів

📚 Тематика
#php
#architecture
#symfony
#composer
#docker
#sql
#testing
#designpatterns
#solid
#oop
#ddd
#jsonrpc
#microservices
#documentations
#algorithm

🛠 Практика
#examples — корисне
#tools — інструменти, утиліти
#tips — короткі поради
#mistakes — типові граблі
#refactor — приклади рефакторингу
#debug — про дебаг, логування, профілювання
#phpstorm — найкраща IDE
#ai — ШІ помічник

👨‍🏫 Освіта / досвід
#videoarchive — архівне відео з (вебінарів)
#course — матеріали з курсів
#question — питання до аудиторії
#talks — думки й міркування
#4students — для випускників

😄 Гумор і факапи
#game — інтерактивна гра
#rants — бурчання з досвідом
#wtf — код або ситуації, від яких немає слів
#humor — ІТ гумор
#quote — цитати від студентів і колег

Інше
#longread
#holywar
#rating
#career
#work
#series — серія статей

UPD:
В коментарях під цим постом можна писати запити на теми, що вас цікавлять

#longread #documentations #examples
Документація, яку хочеться читати! Але це не точно... 🤷‍♂️

Зазвичай тема документації — це болюча тема в багатьох компаніях. Часто тому, що її або ніколи не пишуть, або пишуть «щоб було», або загальними фразами тому що «і так зрозуміло».
Раніше і я грішив цим: не було ні часу, ні мотивації розписувати очевидне.
Але не цього разу.

Зараз я і моя "команда молодая" розробляємо сервісоорієнтовану платформу для FMCG. Звісно задач валом і тому сайт для маркетингу ми робити не встигаємо, відтак (не з мого рішення) взяли підрядників. Сказали: ось ці хлопці робитимуть нам сайт на WordPress. І серед іншого — там має бути мультимовний каталог продукції з фасетними фільтрами.

Пишіть у коментарі, якщо не знаєте, що це таке і чому це маст-хев для e-commerce.

Поспілкувавшись із WordPress-розробником, я зрозумів, що якщо він і витягне цю задачу, то зробить це десь за рік. Тому вирішив допомогти. Як же їм поталанило, що у нас вже є готовий мікросервіс catalog, побудований за EAV-патерном (Entity-Attribute-Value), де кожен параметр — це окремий об'єкт у структурі, і це одразу дає можливість будувати фасетні фільтри з коробки

Колись напишу окремий пост про бібліотеку, яку я для цього зробив, дайте знати якщо це цікаво.

Коротше надав йому API — замість того, щоб він пилив свою адмінку, фільтри, хостинг картинок тощо.
Для нас — ще один клієнт до додатку, для нього — купа зекономленого часу.

І підійшов я до цього з ентузіазмом: розписав максимально детальну API-документацію. І філософію, і особливості, і як краще підходити до інтеграції. Зробив обгортку над markdown, щоб генерувати сторінки як треба. 🔗 Ось результат мені не соромно виставити це на загал.

І що ви думаєте? Все, що було написано в блоках warning і attention, він проігнорував (чи просто не читав) — і по кожному кейсу потім писав мені:

“какая-то ашипка”
“штото нє работаєт”

Поки я не розжував йому все персонально.

———
Мораль історії:

Скільки б часу ти не витратив на те, щоб зробити щось зрозумілим — знайдеться той, хто це проігнорує.

а ще:

У вас тепер є майже унікальна можливість подивитися, як виглядає реально доступно написана документація API — по версії Доктора 😄

#longread #examples #architecture #talks

🧱 Наскільки складним може бути конструктор?

Якось на курсі php-pro, коли я розповідав про SOLID один із студентів запитав:

«А скільки залежностей можна вважати нормальним у конструкторі?
Три? Чотири? Пʼять — це вже погано?»

Хороше питання. Але відповідь трохи не в площині "цифри".
Є популярна думка, що конструктор має бути максимально простим, бо "інакше це ознака порушення SRP".
Я з цим не згоден. Бо сам факт великої кількості залежностей — не обовʼязково погано, якщо твій обʼєкт має чітку відповідальність, але для її реалізації потребує 6–8 залежностей — це нормально. Проблема, якщо вони несумісні логічно або обʼєкт намагається робити забагато.
Але якщо обʼєкт координує складну, але єдину бізнес-дію — багато залежностей це нормально і навіть правильно.

class OrderFinalizer
{
    public function __construct(
        private OrderRepository $orders,
        private InventoryService $inventory,
        private DiscountCalculator $discounts,
        private TaxService $tax,
        private PaymentGateway $payments,
        private LoggerInterface $logger,
        private EventDispatcherInterface $events,
    ) {}
}

Так, тут 7 залежностей і всі вони працюють на одну дію — фіналізацію замовлення.
Це SRP у чистому вигляді: складна операція, але одна відповідальність.

Якщо ми почнемо це «розмазувати» по фабриках або передавати 1 загальний сервіс, типу AppContext, — от тоді це буде гірше.
Бо замість явного контракту ти отримуєш непрозору магію.
Незрозуміло, що реально потрібно класу — тільки при читанні коду видно, що витягується з контексту.

Це ускладнює:
🔹 рефакторинг (бо клас виглядає як чорна діра)
🔹 тестування (все мокаєш, бо неясно що саме юзається)
🔹 зрозумілість (новачок не зчитує залежності по сигнатурі)

Висновок

Не бійся передавати багато залежностей, якщо вони всі потрібні.
Бійся ховати залежності в "зручні" обгортки типу AppContext.

Код має бути явним. Це і є архітектура.