#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
А якщо будуть питання — ставте їх в коментарях, попрошу Славу поглядувати на коменти, він точно розкаже і пояснить краще за мене 😉

#game
Спробуємо нову ранкову активність
Вгадай вираз по емоджі
Почнемо з простого

🐘👶💻⚰️

Варіанти пишіть в коментарі за спойлером

#course #algorithm #series

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

O(n) – Лінійна складність

Це найпоширеніший тип складності, який ви бачите щодня.

Уявімо, що у вас є масив з 1000 елементів і потрібно знайти одне значення. Якщо масив не відсортований, іншого шляху, окрім як перевірити кожен елемент, просто немає. І саме це означає O(n) — час виконання зростає прямо пропорційно до кількості елементів.

📌 Приклад: Лінійний пошук у масиві

function linearSearch($array, $target) {
    for ($i = 0; $i < count($array); $i++) {
        if ($array[$i] === $target) {
            return $i;
        }
    }
    return -1;
}

Класика. Від foreach, до array_map або array_filter — більшість ваших ітерацій працює саме в O(n).

O(n) — це ще не погано. Це нормально. Але якщо обробляєте мільйони записів — треба думати, як зробити краще.

🧠 Завтра обговоримо O(log n) і двійковий пошук.

⬅️ Попередня складність | Наступна складність ➡️

#course #php #longread

match !== switch

Вже відносно давно — починаючи з PHP 8.0 (а це вже 1,5 роки тому 😳) — зʼявився новий інструмент: match. Але практика співбесід (як джунів, так і мідлів) показує, що багато хто, в кращому випадку, просто знає про нього, але не використовує у повсякденному коді. Основна причина — поверхневе розуміння: існує думка, що це просто ще один синтаксичний цукор над switch чи if/else.
❗️Але це не так.

Сьогодні я спробую пояснити, чому match — це окремий інструмент із своїми перевагами і призначенням.

1️⃣ match повертає значення 🔄
match — це вираз, а не інструкція. Він завжди повертає результат, який потрібно привласнити змінній:

$taxRate = match($countryCode) {
    'UA' => 0.20,
    'PL' => 0.23,
    'DE' => 0.19,
    default => 0.0,
};

switch та if/else, на відміну від цього, нічого не повертають. Якщо ви хочете отримати результат — доводиться оголошувати змінну перед умовою, потім в кожному кейсі встановлювати їй значення.

2️⃣ Обовʼязкове покриття всіх кейсів ✅
match зобовʼязує розробника обробити всі можливі варіанти або вказати default. Якщо не вказано відповідність — буде UnhandledMatchError. Це значно знижує ризики неочевидних помилок.

$action = match($input) {
    'start' => 'Запуск',
    'stop' => 'Зупинка',
    default => 'Пауза',
};

У switch та if/else будь-який відсутній case просто проігнорується.

3️⃣ Завжди суворе порівняння (===), а не вільне (==) 🧠
У match значення порівнюються суворо — без приведення типів. Це ще один реверанс php в бік суворої типізації і плюс до безпеки та передбачуваності:

match(0) {
    false => 'false', // ❌ UnhandledMatchError
    0 => 'zero',      // ✅ буде виконано
};

switch (0) {
    case false:
        echo 'false';  // ✅ буде виведено
        break;
    case 0:
        echo 'zero';   // ❌ сюди не дійде
        break;
}

☝️ switch у цьому випадку вибере false як відповідність до 0, що може призвести до неочікуваної поведінки.

4️⃣ Немає fallthrough і break 🧱
У switch завжди є ризик забути break, і тоді код "провалиться" в наступний кейс. Це класичне джерело помилок. У match кожен кейс — це окреме правило, і немає поняття break чи переходу до наступного.

Хто не знає про що мова, просто виконайте цей код:

$value = 2;
switch ($value) {
    case 1:
        echo 'one';
    case 2:
        echo 'two';
    case 3:
        echo 'three';
}

5️⃣ Виховує декларативність ✨
match заохочує до декларативного стилю — без зайвої логіки в тілі конструкції. Він не дозволяє писати довгі блоки коду в кожному кейсі, лише вирази. Це змушує структурувати код краще:

return match(true) {
    $x > 0 => 'позитивне',
    $x < 0 => 'негативне',
    default => 'нуль',
};

6️⃣ Продуктивність: O(1) доступ по значенню ⚡️
match працює аналогічно хеш-мапі: якщо йдеться про скалярні значення (int, float, string, bool), він здійснює пошук у константний час — по складності алгоритму O(1). Це дає велику перевагу над switch, де кожен case порівнюється послідовно (складність алгоритму O(n)):

// match — O(1):
$color = match($code) {
    'R' => 'Red',
    'G' => 'Green',
    'B' => 'Blue',
    default => 'Unknown',
};

// switch — O(n):
switch ($code) {
    case 'R': $color = 'Red'; break;
    case 'G': $color = 'Green'; break;
    case 'B': $color = 'Blue'; break;
    default: $color = 'Unknown';
}

———
Висновки 🎯

match — це не альтернатива switch чи if/else, а окремий інструмент для ситуацій, де важлива чіткість та суворість, тобто для всіх ситуацій з умовами

Він допомагає уникати класичних помилок з switch і заохочує до чистішого, передбачуваного коду

Він швидкий: прості значення шукаються у константний час.

❗️Якщо ти ще не використовуєш match у повсякденній роботі, саме час спробувати його у своїй наступній задачі.
Як кажуть: "Відчуй різницю" 😉