#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 у повсякденній роботі, саме час спробувати його у своїй наступній задачі.
Як кажуть: "Відчуй різницю" 😉

#game
Всім раночок
1. 👤📦🔐
2. 👴↕️👨‍🦰↕️👦
3. 🎭🔁🎯
4. 🧠🗺️👻

Якщо здогадалися які чотири поняття тут зашифровані, пишіть в коментарях, але не забувайте приховати відповідь під спойлером

#course #algorithm #series

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

O(log n) – Логарифмічна складність

Це одна з найефективніших складностей, яку тільки можна досягти в реальних задачах з великим обсягом даних.

📚 Уявімо, що в нас є телефонна книга з 1 000 000 імен, і ми шукаємо конкретне. Лінійно довелося б перевірити кожне імʼя і це зайняло б безліч часу. Але якщо ми будемо розрізати масив навпіл кожного разу, відкидаючи половину, яка нам точно не підходить — отримаємо двійковий пошук, і результат знайдеться за ~20 кроків. Це й є логарифмічна ефективність.

Такий підхід працює лише з відсортованими даними. І саме це лежить в основі багатьох пошукових і оптимізаційних алгоритмів.

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

function binarySearch($array, $target) {
    $left = 0;
    $right = count($array) - 1;

    while ($left <= $right) {
        $middle = floor(($left + $right) / 2);
        if ($array[$middle] === $target) return $middle;

        if ($array[$middle] < $target) {
            $left = $middle + 1;
        } else {
            $right = $middle - 1;
        }
    }
    return -1;
}

🔄 Кожний крок зменшує область пошуку вдвічі. І замість мільйона перевірок — лише кілька десятків. Ось чому O(log n) — максимально швидкий.

🧐 У наступному пості поговоримо про O(n log n) — і як працюють ефективні сортування.

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

#talks #4students

🫣 Сором — найкращий початок

Який сором. Цього тижня я дуже незадоволений собою. Якось все сумбурно і неструктуровано.

Зазвичай так почуваються джуни на першому тижні в новому проєкті.
І справді — вкататись у складний проєкт це ще той квест. Давай спробуємо розібратися, як не потонути і швидше «стати своїм».

Перш за все відкинь амбіції і прийми те, що наразі твій value для команди дуже малий, тому твоя мета на перші тижні — не стільки виконувати задачі, скільки навчитися орієнтуватися в проєкті. Хоча задачі теж самі себе не зроблять 😉

1. Ознайомся з Code Style команди та налаштуй IDE так, щоб не витрачати енергію на дрібниці.
2. Поступово ознайомся з тим як виглядає система верхньорівнево, якщо є схеми або документація, починай на них дивитися.
3. Не пірнай одразу в усе. Зосередься на тому, що треба вирішити сьогодні.
4. Якщо на проєкті SOA, тобі потрібна мапа сервісів, які вже існують, за що вони відповідають, але як і в попередній пораді, в першу чергу зосередься на тій області в якій ти будеш виконувати задачі.
5. Ну і, звісно, став запитання, куди ж без цього? Мовчазний джун — це завжди гірше, ніж "надокучливий", адже розумно сформульоване питання — часто надає відповідь автоматично.

Якщо тобі теж соромно від своєї початкової ефективності — це норм.
Хоча ні, не норм - це дуже добре. Бо сором — це сигнал, що ти бачиш планку. А значить — зможеш її перестрибнути.

🎉 100 підписників!
Дякую кожному і кожній, хто читає, коментує і надсилає свої думки.
Далі буде ще більше корисного контенту та прикладів з реальної розробки, тож запрошуйте ваших друзів і колег, щоб нас ставало ще більше.

🚀 Погнали далі!

І не забувайте донатити на ЗСУ, щоб у нас і далі була можливість працювати
💙💛🇺🇦♥️🖤

#game

Всім доброго ранку
Сьогодні в нас щось, що дуже полюбляє Laravel:

🪄📦📤

Не забувайте приховувати відповіді під спойлером 😉

UPD: слово "магічний" вже вгадали
Напевно підказка про Laravel збиває вас з пантелику

Це словосполучення на співбесіді може звучати так:

"Які магічні .... в PHP ти знаєш?"

Загаданий один з них.