Я Олександр Майстренко, ІТ-директор і викладач 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.

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

#tips #talks

Як запамʼятати зрозуміти патерни проєктування?

Ті, хто проходили мої курси, вже знайомі з цими порадами, але я повторю їх для інших підписників.

Колись я, як і більшість із вас, зубрив патерни перед співбесідою і тримав схрещені пальці 🤞, щоб тільки не спитали. А потім — спокійно видихав і забував про них до наступного разу 😮‍💨
Але коли я все ж вирішив з ними розібратися — зрозумів, що частину з них я й так використовую майже щодня в роботі 🧑‍💻, просто не знав, що це патерн і як він називається.

Тому я випрацював для себе схему як їх зрозуміти 👇

1️⃣ Не зубріть патерни теоретично — реалізовуйте їх.
🔹Щоб запамʼятати, як працює патерн — його треба реалізувати, тобто написати руками ✍️
🔹А якщо, все ж, хочете легко їх завчити, то вчіть по їх типах (структурні, поведінкові та породжувальні) 🧩
Так буде легше співвіднести назву з розумінням для чого він, і тоді ніколи не стане необхідності порівняти стратегію з фабрикою, бо вони відносяться до різних груп.
А порівнювати логічно те, що схоже, а не те, що різне. 🧠

2️⃣ Починайте не з назви, а з проблеми.
Патерн — це не заклинання 🧙‍♂️ Це рецепт вирішення конкретної проблеми.
Тому вчити треба так:

"Є така-то проблема → вона вирішується таким, таким і таким патерном."

Таке мислення запамʼятовується та потім працює і на співбесіді, і на практиці 🛠

3️⃣ Асоціюйте поведінку, яку описує патерн, з чимось для вас знайомим.
Щоб швидко зрозуміти суть — звʼяжіть її з чимось знайомим 🤔
Наприклад, Builder можна порівняти з реальним прорабом на будівництві 👷
Ми проговорюємо йому всі побажання в довільному порядку, він все записує, складає правильний порядок робіт, але працювати почне лише коли ми дамо йому гроші 💵

$builder = new HouseBuilder();

$builder
    ->setWalls('цегляні')
    ->setRoof('металева')
    ->setWindows('панорамні')
    ->setGarage('на дві машини')
    ->setFloorCount(2)
    ->setHasBasement(true)
    ->setFence('деревʼяний')
    //...
    ->setSecuritySystem('Ajax');


//...
// Прораб виставляє рахунок, який ми сплачуємо
$builder->getInvoice()->pay();


//...
// І будує лише якщо він сплачений
if ($builder->getInvoice()->isPaid()) {
    $house = $builder->build();
}

4️⃣ Зробіть сайт refactoring.guru своїм настільним чтивом, якщо ще цього не зробили.
Читайте по одній статті у вільний час:
🚬 на перекурі,
☕️під ранкову каву,
🚽сидячі на унітазі (хоча ця порада не для всіх 😉)

———
Висновок такий:

Патерни — це не страшилка для співбесіди, а спосіб мислення.
Коли ти їх розумієш, а не просто знаєш назви, — ти починаєш бачити їх у реальних задачах, і тоді більше не доводиться вигадувати велосипед кожного разу.

#course #algorithm #series

🧵На скільки ефективний мій код? 1/8

Складність алгоритму — це один із фундаментальних показників ефективності.

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

І почнемо ми з найпростішої, але при цьому дуже важливої складності — O(1), або константної складності.

———

O(1) – Константна складність

Що це означає? Що алгоритм завжди виконується за однакову кількість операцій, незалежно від обсягу даних. Це золото. Це те, що хочеться бачити в критичних місцях: перевірка прав, доступ до кешу, отримання значення з асоціативного масиву.

📌 Приклад: Пошук елемента в хеш-таблиці

$array = ['a' => 1, 'b' => 2, 'c' => 3];
$value = $array['b'];

У цьому прикладі ми одразу знаходимо значення за ключем. Час виконання не залежить від розміру $array — хоч там 3 елементи, хоч 3000. Жодних циклів або рекурсії — це і є O(1).

💡 Цей тип складності зустрічається в PHP та інших технологіях частіше, ніж здається — і чим краще ви його впізнаєте, тим точніше зможете писати оптимальний код. Так, наприклад, працює сховище Redis, Cookie, LocalStorage, кеші фреймворків.

🧠 Завтра поговоримо про O(n) — класичну лінійну складність, яку ви точно вже бачили і робите щодня в кожному циклі.

📎 А поки згадайте інші приклади технологій які використовують цю складність алгоритму, можете поділитися вашими думками в коментарях.

Наступна складність ➡️

#devtools #longread

🐘Чи може PHP бути функціональною мовою програмування?

Нещодавно згадав про бібліотеку мого колишнього тімліда і гарного товариша Slava Basko, яка дозволяє писати PHP-код у функціональному стилі. Власне, цей пост — про мій досвід знайомства з нею, рефлексію та порівняння з підходами, які я використовую у своїй щоденній практиці.

Ті, хто мене знають, знають і про мою любов до ООП, архітектурної чистоти і чіткого контролю залежностей. Власне, я став таким не в останню чергу завдяки Славі — колись саме він відкрив мені світ ООП. Але минули роки, і Слава захопився мовою Haskell та загалом функціональним підходом у програмуванні. І от результат — він створив бібліотеку, яка переносить функціональний підхід в PHP-світ.

В чому сенс бібліотеки?

Бібліотека дозволяє:
🔹писати декларативний код, де немає проміжних змінних і імперативних конструкцій
🔹використовувати каррінг, pipe, compose, partial, тощо
🔹створювати читабельні ланцюжки трансформацій без втрати контексту

Приклад — зведення кількості товарів у масиві:

$totalQty = compose(sum, pluck('qty'))($products);

Інший приклад — форматування опису товарів:

$commonDescription = pipe(
    pluck('description'),
    map(unary('trim')),
    select(unary('strlen')),
    join(', '),
    take(34),
    partial_r('trim', ', ')
)($products);

Порівняння Функціонального підходу(ФП) з ООП та Процедурним підходом (ПП)

1️⃣ Читабельність:

ПП: Прямолінійна, але з купою змінних
ООП: Структуровано, але часто занадто обʼємно
ФП: Лаконічно, але може бути незвично

2️⃣ Повторне використання:

ПП: Складно масштабувати
ООП: Абстракції, спадкування
ФП: Композиція, замикання

3️⃣ Тестування:

ПП: Залежить від глобальних станів
ООП: Часто потребує моків
ФП: Простота завдяки чистим функціям

4️⃣ Гнучкість:

ПП: Низька
ООП: Залежить від скіла розробника, середня або висока
ФП: Висока при трансформаціях

5️⃣ Контроль залежностей

ПП: Відсутній
ООП: Повний
ФП: Частково можливий, значно складніше відслідковувати, або я не розібрався

6️⃣ Коли це зручно?

ПП: Якщо обробляєш масиви або структури даних
ООП: Якщо маєш багато етапів трансформації
ФП: Якщо хочеш відмовитись від змінних і foreach

Висновок

Це не звичний для більшості PHP-розробників підхід. Але він працює, зручний, і я точно буду використовувати його всередині методів класів, де потрібно швидко і чітко трансформувати дані.
Чисті функції і pipe чудово лягають на обробку DTO, валідацію, генерацію описів тощо.

Рекомендую подивитись.
🔗 https://packagist.org/packages/slava-basko/functional-php
А якщо будуть питання — ставте їх в коментарях, попрошу Славу поглядувати на коменти, він точно розкаже і пояснить краще за мене 😉