#holywar #4students #architecture #php
📤 Відповідаю на питання

Саша привіт! Потрібна твоя консультація. Скажи, будь ласка:
1. чи можна використовувати try catch для управління логікою? Я досі використовував, але сьогодні натрапив на твердження, що це не є хороша практика.

2. Наскільки ресурсозатратне використання вкладених try catch? Прочитав, що сам try catch сам по собі "дешевий", а от throw вимагає багато ресурсів. Це так?

Наперед дякую

1. Чи можна використовувати try/catch для управління логікою?
Так, можна, і це цілком робочий підхід. Питання тут не в "правильно/неправильно", а в тому, яка філософія тобі ближча і що підходить під конкретну архітектуру.

Насправді, це дуже холіварна тема.

Є табір, який каже "винятки тільки для виняткових ситуацій", а є табір, який спокійно використовує їх як механізм flow control. І обидва підходи живуть собі нормально.

Я особисто вважаю, що це питання зручності, а не абсолютна істина, мені зручніше обʼєктно-орієнтований підхід, ІМХО якщо код читається краще — значить підхід має право на життя.

Приклад:

try {
    $code = $repo->getByUrl($url);
} catch (NotFoundException) {
    $code = $this->generateAndSave($url);
}

У такій ситуації це працює природно і зрозуміло: "немає? створи". Немає нічого поганого в тому, щоб ловити конкретний виняток і робити fallback-логіку.

Проблеми починаються тільки тоді, коли exception використовується замість звичайного if у найпростіших місцях, або коли репозиторій починає кидати винятки там, де очікувано повертати null. Але то вже питання дизайну коду.

2. Чи дійсно throw дорогий?
Так, це правда.
try/catch сам по собі майже нічого не коштує. Їх можна хоч вкладати — накладні витрати мізерні, але throw — дорогий, бо PHP генерує backtrace і створює повноцінний Exception-об’єкт, що виїдає процесор.

Тому:
— Якщо throw трапляється рідко — взагалі не проблема.
— Якщо "not found" стає нормальним шляхом виконання (часто), тоді варто задуматись, чи не простіше повертати null або Result-об’єкт — чисто з точки зору продуктивності.

Але й тут все залежить від контексту. Якщо загрузка невелика — різниця взагалі не має сенсу.

Підсумую мою позицію
— Використовувати try/catch для логіки можна. Це не є поганою практикою само по собі, це питання смаку, стилю і команди.
— Якщо код читається краще — я завжди за.
— try/catch дешевий, throw дорожчий, але в реальних проєктах це рідко стає bottleneck’ом.

Якщо тобі це зручно і воно вписується в архітектуру — продовжуй використовувати.

———
Чекаю холіварників у коментах

Про продовження циклу "Чи знаєш ти, що PHP так вміє?" не забув, просто наразі не маю часу 😒

#humor

В суботу о 21:00 готуємося з командою робити реліз мажорної версії

🎉 DOU PHP Meetup — Чорна пʼятниця на DOU

Цього року мене запрошували доповідати на DOU PHP Meetup, але, на жаль, не вийшло поїхати — домовилися перенести мій виступ на наступний рік.

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

💥 Акція 1+1: купуєш квиток — другий прилітає на пошту безкоштовно.
🕺 Акція діє з 27.11 до 30.11

🎫 Якщо йдеш сам — тримай -15%:
FROM_DOCTOR_15 (акції не комбінуються)

👉 https://dou.ua/goto/RK7i

Хто піде — напишіть в коментах, цікаво хто там буде ✌️

#sql #course #4students

Обіцяю, це останній пост про Чорну пʼятницю 😅
Але гріх не поділитись, якщо вже зробили -50% на мій курс по MySQL для Hillel Max.

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

Чорна пʼятниця — нормальний момент почати те, що відкладали місяцями 😉
А якщо ще вагаєшся, то спробуй безкоштовні пробні заняття:
— на Hillel Max
— на моєму YouTube

Хто проходив — можете відписати, чи було корисно 🖤

#️⃣ #php #course #series

🚀 Чи знаєш ти, що PHP так вміє? 8/10
🔒 readonly + accessors
🧱 Стабільні DTO і Value Object без бойлерплейту

📦 Додано у версіях:
readonly — PHP 8.1
accessors — PHP 8.4

💡 Що це дає: можливість створювати об’єкти, дані в яких неможливо змінити випадково,
та новий синтаксис контролю доступу до властивостей через get / set без окремих методів.

🧠 В чому суть:
readonly робить властивість незмінною після ініціалізації —
значення можна встановити лише один раз (зазвичай у конструкторі).

accessors дозволяють додати контроль при читанні та записі властивостей
без класичних геттерів і сеттерів — прямо в тілі класу.

Разом вони створюють ідеальну комбінацію для DTO, VO і конфігураційних класів:
дані незмінні, а доступ контрольований.

🧱 Приклад класичного підходу

class Product {
    private string $name;
    private float $price;

    public function __construct(string $name, float $price)
    {
        $this->name = $name;
        $this->price = $price;
    }

    public function getPrice(): float {
        return $this->price;
    }

    public function setPrice(float $price): void {
        if ($price < 0) {
            throw new InvalidArgumentException('Price must be positive');
        }
        $this->price = $price;
    }
}

✅ працює, але більша частина коду тут тільки заради забезпечення базової інкапсуляції.

⚡️ Тепер те саме — сучасно

class Product {
    public readonly string $name;
    private float $price {
        get => $this->price;
        set => $this->price = max(0, $value);
    }

    public function __construct(string $name, float $price)
    {
        $this->name = $name;
        $this->price = $price;
    }
}

readonly гарантує незмінність імені,
accessors автоматично перевіряють ціну при записі.

Ще приклад — Value Object

class Coordinates {
    public readonly float $lat {
        get => round($this->lat, 6);
    }

    public readonly float $lng {
        get => round($this->lng, 6);
    }

    public function __construct(float $lat, float $lng)
    {
        $this->lat = $lat;
        $this->lng = $lng;
    }
}

👌 Ніяких змін після створення, тільки контрольований доступ при читанні.

⚙️ Де це реально корисно
🔹DTO: запити й відповіді в API;
🔹Value Object: Money, Price, GeoPoint, Range;
🔹Immutable конфігурації: параметри сервісів, константні стани.

🧭 Висновок

readonly і accessors — це крок до справжніх record-класів у PHP.
Вони дозволяють писати чисті, передбачувані структури без тонни бойлерплейту.

🔥 Сьогодні кожен мій DTO — readonly.
———
⬅️ Enums | Атрибути ➡️

#️⃣ #php #course #series

🚀 Чи знаєш ти, що PHP так вміє? 9/10
🏷 Атрибути
✨ Метапрограмування без DocBlock-хаків

📦 Додано у версії: PHP 8.0
💡 Що дає: нативний, типобезпечний механізм додавання метаданих до класів, методів, властивостей та параметрів — без необхідності при їх читанні парсити DocBlock-и та встановлювати сторонні бібліотеки.

❤️ Трохи особистого
До PHP 8.0 в мене був один технічний “біль”, про який знають тільки ті, хто коли-небудь пробував будувати API-документацію чи SDK на основі читання коду.
Скажу лише одне: парсинг DocBlock-ів — це дуже невдячна робота.

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

🧩 Навіщо вони взагалі потрібні?
До PHP 8 метадані доводилося писати так:

/**
 * @Route("/users")
 * @SomeFlag(true)
 */
class UserController {}

Це був просто коментар, який не розбирається стандартними засобами PHP такими як рефлексія. Для аналізу потрібна ще одна бібліотека-парсер, яка мала вгадати, що розробник мав на увазі.

Атрибути роблять метакоментарі типізованими, тепер вони обʼєктні:

#[Route('/users')]
#[SomeFlag(true)]
class UserController {}

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

🧱 Приклади застосування
1️⃣ Доктрина

#[ORM\Entity]
class Product
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    public int $id;

    #[ORM\Column(length: 255)]
    public string $name;
}

2️⃣ Symfony Routing

#[Route('/orders/{id}', methods: ['GET'])]
public function show(int $id) { ... }

3️⃣ Валідація

class RegistrationDTO
{
    #[Assert\Email]
    #[Assert\NotBlank]
    public string $email;

    #[Assert\Length(min: 8)]
    public string $password;
}

4️⃣ Кастомні аттрибути

#[API\Method('user.create')]
class CreateUserRequest
{
    #[API\Param]
    public string $email;

    #[API\Param]
    public string $password;
}

🧠 А що можна робити з атрибутами?

Майже все, що роблять Java/Spring- або C#-атрибути:
🔹позначати класи й методи
🔹додавати метадані
🔹створювати власні декларативні правила
🔹будувати роутинг
🔹маркувати серіалізацію/десеріалізацію
🔹автоматизувати DI/автовіринг
🔹вказувати, як працює кешування чи логування
🔹створювати декларативні контракти для DTO

Фактично — інструмент, щоб писати менше імперативного коду та більше декларативного.

✨ Як створити власний атрибут

#[Attribute(Attribute::TARGET_CLASS | Attribute::TARGET_METHOD)]
class Loggable
{
    public function __construct(
        public string $message = 'default',
        public bool $enabled = true,
    ) {}
}

Використання:

#[Loggable(message: 'Auth attempt')]
class AuthService {}

🔍 Як прочитати атрибут через Reflection

$ref = new ReflectionClass(AuthService::class);
$attrs = $ref->getAttributes(Loggable::class);

$instance = $attrs[0]->newInstance();
echo $instance->message;

📌 Особливо важливо
🔹атрибути це повноцінний об’єкт, а не просто рядок в коментарі
🔹вони мають простір імен
🔹можна типізувати параметри
🔹можна використовувати передові конструкції (enum, readonly, VO)
🔹ідеально комбінуються з DI-контейнерами

🧭 Висновок

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

———
⬅️ readonly + accessors

#humor

На проєкті новий ПМ

А як у вас?

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

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

Дякую, що ви читаєте цей канал. Ціную кожного, хто залишається поруч 🥂

Окрема, глибока і безмежна подяка Збройним Силам України. Саме завдяки вам ми маємо змогу жити, працювати, планувати і зустрічати Новий рік. Низький уклін і шана 🇺🇦🫡

#humor

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

Це відеозапис при зверненні в сапорт зі скаргою, що додаток не дає доступу до камери

#humor
В ІТ забагато англіцизмів, в яких недосвідчена людина може легко заплутатися, пропоную навести порядок і чіткі німецькі назви.

— Team Lead → Gruppenführer → Групенфюрер
— Tech Lead → Technikführer → Технікфюрер
— CEO → Geschäftsführer → Ґешефтсфюрер
— CTO → Obertechnikdirektor → Обер-технік-директор
— Project Manager → Projektleiter → Проєктляйтер
— Scrum Master → Zeremonienleiter → Церемонієнляйтер
— Backend Developer → Anwendungsentwickler → Анвендунґс-ентвіклер
— Frontend Developer → Oberflächen-Entwickler → Оберфлехен-ентвіклер
— Fullstack Developer → Universal-Entwickler → Універсаль-ентвіклер
— DevOps Engineer → Betriebsingenieur → Бетрібс-інженер
— Manual QA → Prüfer → Прюфер
— BI Analyst → Berichtsanalytiker → Беріхтс-аналітікер
— UX/UI Designer → Benutzeroberflächen-Gestalter → Бенуцероберфлехен-ґештальтер

Тепер одразу ясно, хто відповідальний 😈

Standup завтра о 11:00, точніше Stehbesprechung → Штейбешпрехунґ

#course #4students
Ще перед Новим роком я завершив розробку відеокурсу по MongoDB, і тепер він повністю готовий 🎬

Колись казали, що найкращий подарунок — це книга. Я ж переконаний, що найкращий подарунок — це знання.

Зараз на платформі вже діє –25% на всі курси, але напередодні Дня святого Валентина я домовився про додаткову персональну знижку для вас: на мої курси зробили промокод, який дає ще –25% додатково, тобто з ним ви можете придбати один з моїх курсів зі знижкою 50%.

Мої курси:
• Бази даних: SQL (6 годин відео, 24 заняття, 24 тести, 3 практичні завдання)
• MongoDB: Глибинне занурення в управління нереляційною базою даних (3 години відео, 19 занять, 19 тестів, 18 практичних завдань)

Промокод: DOCTOR_LOVE

Зробіть подарунок своїй половинці! Або собі 😉

#humor

Коли в п'ятницю вирішив відрефакторити свій старий код, а затягнуло на всі вихідні

#tools #4students #git
💡 Інструмент, який пояснює Git, а не змушує зазубрювати команди

Якщо ти користуєшся GIT в роботі, але не розумієш як це працює і що окрім commit, pull та push є ще безліч можливостей, дуже раджу тобі спробувати цей інструмент:

👉 Learn Git Branching — це інтерактивний симулятор git-репозиторію прямо в браузері.
Не туторіал! Не стаття! Не відео!
Це інструмент для практичного навчання.

Ти вводиш git-команди — і одразу бачиш, що відбувається з історією комітів, HEAD, branch’ами, merge і rebase.

🚀 Що там є:
🇺🇦 нативна українізація
🔹 візуалізація commit graph у реальному часі
🔹 рівні як у грі (від basic до remote workflow)
🔹 можна ламати репу без страху 🙂
🔹 sandbox режим для пояснення команд команді або студентам

Фактично це git-пісочниця + тренажер, де дерево комітів змінюється після кожної команди, що сильно прискорює розуміння branching-моделі Git

Це найшвидший спосіб зрозуміти такі можливості як rebase, а не просто знати, що є така команда

📌 Особливо корисно:
🔹джунам
🔹тим, хто працює через IDE чи GUI кнопки
🔹розробникам, які бояться merge conflict’ів 😄
🔹викладачам (ідеально показувати live)

⚡️ 15–20 хв — і багато речей у git перестануть бути магією

#architecture #videoarchive

🚀 2 роки ентерпрайс розробки за 2 хвилини 45 секунд

Виклав відео еволюції від пустого репозиторію до робочого enterprise-продукту.

Без презентації, без красивих слайдів. Тільки реальна Git-історія розробки.

За цей час було побудовано:
— backend на SOA CQRS архітектурі
— Saga orchestration та event-driven взаємодію сервісів
— React PWA
— окрему адмінку з мікрофронтендами
— CI/CD процеси
— десятки сервісів, інтеграцій і доменів

І найцікавіше — все це зроблено мінімальною кількістю людей (менше вже просто неможливо).

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

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

🎬 Відео тут: https://youtu.be/mesk-CiGuFU

Якщо вам цікаві теми архітектури, SOA, масштабування продуктів і розробки без корпоративних казок — підписуйтесь на цей Telegram-канал та мій YouTube.