Питання на співбесіді PHP-розробника

== порівнює значення з приведенням типів, === — значення і тип без приведення. Наприклад, '1' == 1 дає true, а '1' === 1 — false.

У PHP 8 правила порівняння рядків із числами стали суворішими: 0 == 'abc' тепер false. На практиці краще завжди використовувати === і declare(strict_types=1), щоб уникнути несподіваних результатів.

Інтерфейс описує контракт — набір методів без реалізації, і клас може реалізувати кілька інтерфейсів. Абстрактний клас може містити спільний код і стан, але клас успадковує лише один такий клас.

Інтерфейс обирають, коли важлива можливість підмінити реалізацію (наприклад, PaymentGateway для різних платіжних систем). Абстрактний клас — коли кілька класів мають спільну логіку, яку не хочеться дублювати.

Це атака, коли дані користувача потрапляють у SQL-запит як частина коду. Наприклад, рядок ' OR 1=1 -- у полі логіну може обійти перевірку.

Захист — підготовлені запити (prepared statements) з параметрами через PDO або query builder / Eloquent, які роблять це автоматично. Ніколи не склеюйте SQL із вхідних даних, а для назв колонок у сортуванні використовуйте білий список.

Міграції — це версіоновані PHP-файли, які описують зміни структури бази даних: створення таблиць, колонок, індексів. Вони зберігаються в Git разом із кодом.

Завдяки міграціям кожен розробник і кожен сервер отримують однакову схему БД командою php artisan migrate, а зміни можна відкотити через migrate:rollback.

Скалярні (прості) типи: int, float, string, bool. Складені: array, object, callable, iterable. Спеціальні: null і resource.

Простий тип зберігає одне значення, складений — набір значень або структуру. Масиви в PHP копіюються при присвоєнні (copy-on-write), а об'єкти передаються за «дескриптором»: дві змінні вказують на той самий об'єкт.

В одинарних лапках рядок береться майже буквально: змінні не підставляються, працюють лише \' і \\. У подвійних лапках підставляються змінні ("Привіт, $name", "{$user->name}") і спецсимволи \n, \t.

Для довгих текстів є heredoc (як подвійні лапки) і nowdoc (як одинарні). Різниця в швидкодії мізерна — обирають за зручністю.

Явне приведення — (int) $x, (string) $x, intval(). Неявне відбувається автоматично: у арифметиці ('5' + 3 дає 8), при порівнянні через ==, у логічному контексті (if ($x)), при конкатенації чисел із рядками.

У PHP 8 правила стали суворішими: 'abc' + 1 кидає TypeError, а 0 == 'abc' тепер false. Щоб уникати сюрпризів, використовують declare(strict_types=1) і ===.

null означає відсутність значення, false — логічне «ні», 0 — число нуль. Це три різні типи, але в логічному контексті всі вони хибні, і null == false == 0 при нестрогому порівнянні.

Саме тому функції на кшталт strpos() перевіряють через === false: позиція 0 — це знайдений рядок на початку, а не помилка.

• isset($x) — змінна існує і не дорівнює null; не видає попередження для неіснуючих змінних і ключів;
• empty($x) — змінна не існує або «порожня»: '', 0, '0', [], null, false;
• is_null($x) — значення дорівнює null; для неіснуючої змінної видасть попередження.

Пастка empty(): рядок '0' вважається порожнім, тому для форм краще перевіряти явно.

Масив у PHP — упорядкована хеш-таблиця «ключ → значення». В індексованому масиві ключі — цілі числа ([10, 20, 30]), в асоціативному — рядки (['name' => 'Олена', 'age' => 25]).

Технічно це одна структура, тому ключі можна змішувати. Масиви зберігають порядок додавання елементів. Для перевірки, що масив — «список» з ключами 0..n-1, є array_is_list() (PHP 8.1).

• За ключем: array_key_exists('email', $data) або isset($data['email']). Різниця: isset поверне false, якщо ключ є, але значення null;
• за значенням: in_array($value, $array, true) — третій параметр вмикає строге порівняння;
• позицію значення повертає array_search().

Для частих перевірок у великому масиві швидше перевернути його через array_flip() і шукати за ключем.

• array_map перетворює кожен елемент і повертає масив тієї самої довжини;
• array_filter лишає елементи, для яких колбек повернув true (ключі зберігаються — часто потрібен array_values);
• array_reduce згортає масив до одного значення, наприклад суми.

$prices = [100, 250, 40];
$withVat = array_map(fn($p) => $p * 1.2, $prices);
$expensive = array_filter($prices, fn($p) => $p > 50);
$total = array_reduce($prices, fn($sum, $p) => $sum + $p, 0);

foreach перебирає масиви й ітеровані об'єкти — найзручніший для колекцій. for — коли потрібен лічильник і відома кількість ітерацій. while перевіряє умову до кожної ітерації, do-while — після, тому виконується хоча б один раз.

У foreach із посиланням (foreach ($arr as &$v)) після циклу треба робити unset($v), інакше наступний цикл може зіпсувати останній елемент.

break повністю виходить із циклу (або switch), continue пропускає решту поточної ітерації й переходить до наступної.

Обидва приймають число рівнів для вкладених циклів: break 2 виходить із двох циклів одразу. Але глибока вкладеність — сигнал, що код варто винести у функцію з return.

++ збільшує значення на 1, -- зменшує. Префіксна форма ++$a спочатку змінює змінну, потім повертає нове значення. Постфіксна $a++ повертає старе значення, а потім змінює змінну.

$a = 5;
$b = $a++; // $b = 5, $a = 6
$c = ++$a; // $a = 7, $c = 7

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

function countItems(array $tree): int {
    $count = 0;
    foreach ($tree as $node) {
        $count += 1 + countItems($node['children'] ?? []);
    }
    return $count;
}

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

Функція — іменований блок коду, який приймає аргументи й повертає результат. За замовчуванням аргументи передаються за значенням: функція працює з копією, оригінал не змінюється.

За посиланням — через &: function addItem(array &$cart, $item) { $cart[] = $item; } змінює оригінальний масив. Посилання ускладнюють розуміння коду, тому частіше повертають новий результат. Об'єкти й так не копіюються — функція може змінити їхні властивості.

Аргумент за замовчуванням має значення, якщо його не передали: function greet(string $name = 'Гість'). Необов'язкові параметри ставлять після обов'язкових.

Іменовані аргументи (PHP 8.0) дають змогу передати значення за назвою параметра в будь-якому порядку й пропустити необов'язкові:

htmlspecialchars($text, double_encode: false);

Це робить виклики з багатьма параметрами зрозумілішими.

Типи вказують, які значення приймає й повертає функція: function total(array $items): float. PHP перевіряє їх під час виконання й кидає TypeError при невідповідності.

Без strict_types скалярні значення приводяться (рядок '5' стане 5 для int), з declare(strict_types=1) — ні. Типи роблять код самодокументованим і допомагають IDE та статичному аналізу (PHPStan).

• mixed — будь-яке значення, включно з null;
• void — функція нічого не повертає;
• never (PHP 8.1) — функція ніколи не завершується нормально: завжди кидає виняток або викликає exit;
• static як тип повернення — повертається екземпляр того класу, на якому викликали метод (корисно для fluent-інтерфейсів і наслідування).

Nullable-тип дозволяє null: ?string означає «рядок або null». Union types (PHP 8.0) дозволяють кілька типів: int|float, string|null.

У PHP 8.1 з'явилися intersection types (Countable&Iterator — об'єкт реалізує обидва інтерфейси), а в 8.2 — DNF-типи на кшталт (A&B)|null.

• $a ?? $b — повертає $a, якщо воно існує й не null, інакше $b; не видає попередження для неіснуючого ключа;
• $a ?: $b — повертає $a, якщо воно «істинне», інакше $b (тобто 0 і '' теж замінюються);
• $user?->getAddress()?->city — якщо щось у ланцюжку null, весь вираз повертає null без помилки.

Є також ??=: $config['lang'] ??= 'uk';.

Функція поверне null. Якщо в неї оголошено тип повернення void, це очікувана поведінка.

Але якщо вказано, наприклад, : int, а return немає на якомусь шляху виконання, буде TypeError. Статичний аналіз (PHPStan) знаходить такі місця ще до запуску.

Усі підключають і виконують інший PHP-файл. Різниця в поведінці при помилці: include видає попередження й продовжує роботу, require зупиняє скрипт фатальною помилкою.

Варіанти _once підключають файл лише один раз, навіть якщо викликати кілька разів. У сучасних проєктах класи завантажуються автоматично через Composer, і ручні require лишаються хіба що для конфігурації та точки входу.

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

var_dump() виводить тип і значення змінної з усією структурою — для налагодження. Для читабельного виведення масивів є print_r(), а в Laravel — dump() і dd().

Суперглобальні змінні доступні в будь-якому місці коду:

• $_GET — параметри з рядка запиту (?page=2);
• $_POST — дані форми, надіслані методом POST;
• $_SERVER — інформація про запит і сервер (метод, URI, заголовки, IP);
• $_SESSION — дані сесії користувача (після session_start());
• $_COOKIE — cookies, які надіслав браузер.

Також є $_FILES, $_ENV, $_REQUEST. Усі вхідні дані потрібно валідувати — їх контролює користувач. У фреймворках замість них використовують об'єкт Request.

Регулярний вираз — шаблон для пошуку й перевірки тексту. У PHP — функції preg_match, preg_replace, preg_split.

// перевірка українського номера телефону
if (preg_match('/^\+380\d{9}$/', $phone)) { ... }
// прибрати все, крім цифр
$digits = preg_replace('/\D+/', '', $input);

Для email краще filter_var($email, FILTER_VALIDATE_EMAIL), ніж власний складний вираз. Для UTF-8 тексту потрібен модифікатор u.

Генератор — функція з yield, яка повертає значення по одному й призупиняється до наступного запиту. Значення обчислюються ліниво, тому генератор не тримає всі дані в пам'яті.

function readLines(string $file): Generator {
    $h = fopen($file, 'r');
    while (($line = fgets($h)) !== false) {
        yield $line;
    }
    fclose($h);
}
foreach (readLines('big.csv') as $line) { ... }

Так можна обробити файл на гігабайти з мінімальним споживанням пам'яті. У Laravel схожу ідею реалізують lazy() і cursor().

Замикання — анонімна функція, яку можна зберегти в змінну й передати як аргумент. Зовнішні змінні вона не бачить автоматично — їх передають через use:

$min = 100;
$filtered = array_filter($prices, function ($p) use ($min) {
    return $p >= $min;
});

use копіює значення на момент створення; use (&$x) передає за посиланням. Стрілкові функції fn($p) => $p >= $min захоплюють зовнішні змінні автоматично.

Простори імен групують класи й запобігають конфліктам назв: App\Models\User і Vendor\Package\User можуть існувати разом.

use App\Models\User; дає змогу писати коротко User, а псевдонім вирішує конфлікт: use Vendor\Package\User as VendorUser;. Простір імен зазвичай відповідає структурі папок — на цьому побудоване автозавантаження PSR-4.

Автозавантаження підключає файл класу автоматично при першому зверненні до класу — не потрібно писати require для кожного файлу.

PSR-4 — стандарт відповідності простору імен і шляху до файлу: App\Services\Payment → app/Services/Payment.php. Composer генерує автозавантажувач за налаштуваннями в composer.json, а після додавання нового простору імен виконують composer dump-autoload.

• 8.0: named arguments, union types, match, nullsafe ?->, constructor property promotion, атрибути, JIT;
• 8.1: enum, readonly властивості, never, fibers, first-class callable strlen(...);
• 8.2: readonly класи, DNF-типи, заборона динамічних властивостей (deprecated);
• 8.3: типізовані константи класів, json_validate(), атрибут #[\Override];
• 8.4: property hooks, асиметрична видимість, array_find(), ліниві об'єкти;
• 8.5: pipe-оператор |>.

На співбесіді важливіше показати, що ви реально використовуєте з цього списку.

Виняток кидають через throw, коли код не може продовжити роботу. try обгортає небезпечний код, catch перехоплює винятки певного типу, finally виконується завжди — для звільнення ресурсів.

try {
    $order = $service->create($data);
} catch (PaymentException $e) {
    report($e);
    return back()->withErrors('Оплата не пройшла');
} finally {
    $lock->release();
}

У PHP 8 більшість фатальних помилок стали винятками класу Error; спільний інтерфейс — Throwable. Не варто «ковтати» винятки порожнім catch.

Клас — шаблон, що описує дані й поведінку. Об'єкт — конкретний екземпляр класу, створений через new. Властивість — змінна всередині об'єкта (дані), метод — функція, що описує дію.

Наприклад, клас Order має властивості $total і $status, метод pay(), а $order = new Order() — конкретне замовлення.

Конструктор __construct() викликається при створенні об'єкта — там ініціалізують властивості й отримують залежності. У PHP 8 є constructor property promotion: public function __construct(private UserRepository $users) {}.

Деструктор __destruct() викликається, коли на об'єкт не лишилося посилань або завершується скрипт. Використовується рідко — для звільнення ресурсів.

• public — доступно звідусіль;
• protected — у самому класі та його нащадках;
• private — лише всередині класу, де оголошено.

За замовчуванням варто робити властивості private і відкривати лише потрібне через методи. У PHP 8.4 з'явилася асиметрична видимість: public private(set) string $name — читати можна всім, змінювати лише всередині класу.

Наслідування дає змогу створити клас на основі іншого через extends: дочірній клас отримує публічні й захищені властивості та методи батьківського і може їх перевизначити.

PHP підтримує лише одиночне наслідування класів. Батьківський метод можна викликати через parent::method(), а final забороняє наслідування класу чи перевизначення методу. Глибоких ієрархій краще уникати — часто доречніша композиція.

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

class Wallet {
    private int $balance = 0;
    public function withdraw(int $amount): void {
        if ($amount > $this->balance) {
            throw new DomainException('Недостатньо коштів');
        }
        $this->balance -= $amount;
    }
}

Баланс неможливо зробити від'ємним ззовні — усі правила зосереджені в одному місці.

Поліморфізм — можливість працювати з об'єктами різних класів через спільний інтерфейс, не знаючи конкретного класу.

interface Notifier { public function send(string $msg): void; }
class EmailNotifier implements Notifier { ... }
class TelegramNotifier implements Notifier { ... }

function notifyAll(array $notifiers, string $msg) {
    foreach ($notifiers as $n) $n->send($msg);
}

Функції байдуже, як саме надсилається повідомлення, — додати новий канал можна без зміни наявного коду.

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

Наприклад, метод $mailer->send($message) приховує SMTP-з'єднання, шаблони й повтори. В PHP абстракцію виражають через інтерфейси й абстрактні класи.

Так. Абстрактний клас може містити звичайні реалізовані методи (публічні, захищені, приватні), властивості та конструктор, а також абстрактні методи без тіла, які мають реалізувати нащадки.

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

Перевизначення (overriding) — дочірній клас оголошує метод із тією самою назвою і сумісною сигнатурою, змінюючи поведінку батьківського. У PHP 8.3 можна позначити його атрибутом #[\Override], щоб помилка в назві одразу виявилася.

Перевантаження (overloading) у класичному сенсі — кілька методів з однаковою назвою й різними параметрами — PHP не підтримує. Схожого ефекту досягають необов'язковими параметрами, union types або магічним __call().

Статичні члени належать класу, а не об'єкту: Math::round(), self::$count. Їх викликають без створення екземпляра.

Доречно для чистих допоміжних функцій без стану та фабричних методів (Money::fromCents(100)). Статичний змінюваний стан — по суті глобальна змінна: його важко тестувати й підмінювати, тому залежності краще передавати через конструктор.

self:: завжди посилається на клас, у якому написано код. static:: — на клас, через який метод реально викликали (пізнє статичне зв'язування).

class Model {
    public static function create(): static { return new static(); }
}
class User extends Model {}
User::create(); // поверне User, а з new self() — Model

На цьому побудовано багато методів Eloquent, як-от User::query().

Магічні методи PHP викликає автоматично в певних ситуаціях:

• __construct() — при створенні об'єкта;
• __get($name) / __set($name, $value) — при читанні чи записі недоступної властивості (так Eloquent дає $user->email);
• __toString() — коли об'єкт використовують як рядок;
• також __call, __callStatic, __invoke, __clone.

Зловживати ними не варто: IDE і статичний аналіз гірше розуміють «магічний» код.

Trait — набір методів і властивостей, який можна «вставити» в кілька класів через use. Це спосіб повторно використати код без наслідування, бо клас може мати лише одного батька.

У Laravel трейти використовують постійно: HasFactory, SoftDeletes, Notifiable. Але трейт із великою кількістю логіки й залежностей ускладнює розуміння класу — часто краще виділити окремий сервіс.

Виникне фатальна помилка конфлікту, якщо його явно не вирішити. Для цього є insteadof і as:

class Report {
    use CsvExport, PdfExport {
        CsvExport::export insteadof PdfExport;
        PdfExport::export as exportPdf;
    }
}

Якщо метод із такою назвою оголошено в самому класі, він має пріоритет над методами трейтів.

Так. Методи трейта копіюються в клас, тому приватні методи трейта стають приватними методами самого класу й доступні всередині нього.

Видимість можна змінити при підключенні: use Helpers { format as public; }.

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

При цьому важливо не створювати заплутаних ланцюжків — складно зрозуміти, звідки в класі взявся метод.

Клас залежить від іншого, якщо використовує його для роботи. Сильне зв'язування — коли клас сам створює залежність (new StripeClient()) і прив'язаний до конкретної реалізації: його важко тестувати й змінювати.

Зменшують через: передачу залежностей у конструктор, залежність від інтерфейсів, а не від класів, принцип єдиної відповідальності та події для слабкого зв'язку між модулями.

Наслідування — відношення «є» (AdminUser є User). Композиція — «має»: об'єкт містить інші об'єкти й делегує їм роботу (OrderService має PaymentGateway і Mailer).

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

• S — Single Responsibility: клас має одну причину для змін. Контролер не має одночасно валідувати, рахувати знижки й надсилати листи;
• O — Open/Closed: розширення без зміни коду — новий спосіб доставки через новий клас, а не новий if;
• L — Liskov Substitution: нащадок має коректно замінювати батька;
• I — Interface Segregation: маленькі інтерфейси замість одного величезного;
• D — Dependency Inversion: залежність від абстракцій (PaymentGateway), а не від конкретних класів.

Краще пояснювати на прикладі зі свого коду.

Dependency Injection — клас не створює залежності сам, а отримує їх ззовні. Це спрощує тестування й заміну реалізацій.

Через конструктор передають обов'язкові залежності, потрібні всьому класу — об'єкт одразу готовий до роботи. Через метод — залежність, потрібну лише одній дії: у Laravel public function store(Request $request, OrderService $orders). Контейнер Laravel підставляє обидва варіанти автоматично.

Singleton гарантує, що клас має лише один екземпляр із глобальною точкою доступу (Database::getInstance()).

Недоліки: прихована глобальна залежність, складність тестування (неможливо підмінити), спільний стан між тестами. Сьогодні замість класичного Singleton використовують контейнер залежностей: $this->app->singleton(...) дає один екземпляр, але його все одно впроваджують явно.

Шаблони проєктування — перевірені рішення типових задач. Поширені в PHP-проєктах:

• Strategy — різні способи доставки чи оплати за спільним інтерфейсом;
• Factory — створення об'єктів залежно від умов;
• Repository — доступ до даних за інтерфейсом;
• Observer — події та слухачі в Laravel;
• Decorator — додати кешування чи логування до сервісу без зміни його коду;
• Adapter — обгортка над стороннім API.

На співбесіді цінують приклад, де патерн вирішив конкретну проблему, а не перелік назв.

• браузер визначає IP-адресу домену через DNS;
• встановлює TCP-з'єднання і для HTTPS — TLS-рукостискання;
• надсилає HTTP-запит (метод, шлях, заголовки, cookies);
• вебсервер (Nginx) передає запит у PHP-FPM, застосунок формує відповідь;
• браузер отримує HTML, розбирає його й довантажує CSS, JS, зображення, потім рендерить сторінку.

Кешування (браузер, CDN) може пропустити частину кроків.

HTTPS — це HTTP поверх TLS: дані шифруються, а сертифікат підтверджує, що ви спілкуєтеся саме з цим сайтом. Через HTTP паролі й cookies передаються відкритим текстом і їх можна перехопити.

Сьогодні HTTPS — стандарт для всіх сайтів: браузери позначають HTTP як небезпечний, а безкоштовні сертифікати видає Let's Encrypt. Також варто вмикати заголовок HSTS.

• GET — отримати дані, не змінює стан сервера; параметри в URL, можна кешувати;
• POST — створити ресурс або виконати дію; дані в тілі запиту;
• PUT — повністю замінити ресурс;
• PATCH — частково оновити ресурс;
• DELETE — видалити ресурс.

GET, PUT і DELETE за специфікацією ідемпотентні: повтор не змінює результат. POST — ні, тому повторна відправка форми може створити дублікат.

• 200 OK — успіх; 201 Created — ресурс створено;
• 301 — постійний редирект (важливо для SEO), 302 — тимчасовий;
• 400 Bad Request — некоректний запит;
• 401 Unauthorized — потрібна автентифікація;
• 403 Forbidden — користувач відомий, але прав немає;
• 404 Not Found — ресурс не знайдено;
• 422 Unprocessable Content — помилки валідації (Laravel повертає його для форм і API);
• 500 — помилка на сервері.

Автентифікація відповідає на питання «хто ви?» — перевірка логіна й пароля, токена, входу через Google. Авторизація — «що вам дозволено?» — чи може цей користувач редагувати цю статтю.

Спочатку автентифікація, потім авторизація. У Laravel за першу відповідає Auth і guards, за другу — Gates і Policies.

HTTP не зберігає стан між запитами, тому сервер створює сесію: генерує ідентифікатор, надсилає його браузеру в cookie, а дані зберігає у себе. При наступному запиті браузер повертає cookie, і сервер знаходить дані сесії.

Дані зберігають у файлах, БД або Redis. Для кількох серверів підходить лише спільне сховище (Redis, БД). Після входу ідентифікатор сесії регенерують, щоб запобігти session fixation.

Cookies — невеликі дані (до ~4 КБ), які браузер зберігає й надсилає з кожним запитом на домен. Використовують для ідентифікатора сесії, налаштувань мови, «запам'ятати мене».

Не зберігають паролі, персональні дані, права доступу у відкритому вигляді — користувач може їх прочитати й змінити. Важливі прапорці: HttpOnly (недоступна з JavaScript), Secure (лише HTTPS), SameSite (захист від CSRF).

• Cookies зберігаються в браузері й автоматично надсилаються на сервер з кожним запитом;
• сесія зберігається на сервері, а в браузері лише її ідентифікатор у cookie;
• localStorage — сховище в браузері до ~5 МБ, на сервер автоматично не надсилається, доступне з JavaScript.

Токени доступу безпечніше тримати в HttpOnly cookie, ніж у localStorage, бо XSS-атака може прочитати localStorage.

REST — стиль побудови API, де все є ресурсами з адресами (/api/orders/15), а дії виражаються HTTP-методами.

Принципи: відсутність стану між запитами (кожен запит містить усе потрібне, наприклад токен), єдиний інтерфейс (методи й статуси HTTP), кешованість відповідей, клієнт і сервер незалежні. На практиці також: іменники в множині в URL, JSON, правильні статуси, пагінація й версіонування (/api/v1).

JSON — текстовий формат обміну даними з об'єктами, масивами, рядками, числами, true/false і null.

$json = json_encode($data, JSON_UNESCAPED_UNICODE | JSON_THROW_ON_ERROR);
$array = json_decode($json, true, flags: JSON_THROW_ON_ERROR);

JSON_UNESCAPED_UNICODE зберігає кирилицю читабельною, другий параметр true повертає асоціативний масив замість об'єкта, а JSON_THROW_ON_ERROR кидає виняток замість тихого null при помилці.

XSS — впровадження шкідливого JavaScript на сторінку через дані користувача (коментар зі <script>). Захист: екранування виводу (htmlspecialchars, {{ }} у Blade), Content-Security-Policy, HttpOnly cookies.

CSRF — сторонній сайт змушує браузер залогіненого користувача надіслати запит на ваш сайт. Захист: CSRF-токен у кожній формі (@csrf у Laravel), cookies з SameSite, і зміна даних лише через POST/PUT/DELETE.

Браузер за замовчуванням забороняє JavaScript читати відповіді з іншого домену (same-origin policy). CORS — механізм, через який сервер дозволяє певним доменам доступ заголовками Access-Control-Allow-Origin тощо.

Для нестандартних запитів (з Authorization, JSON, методами PUT/DELETE) браузер спочатку надсилає preflight-запит OPTIONS. Якщо сервер не відповів потрібними заголовками, запит блокується. Важливо: CORS обмежує лише браузер, а не захищає API від інших клієнтів.

Параметр маршруту — частина шляху, що ідентифікує ресурс: /users/15, де 15 — {id}. Параметри запиту — після ?, для фільтрації, сортування, пагінації: /users?role=admin&page=2.

Правило: те, що визначає «який ресурс», — у маршруті, а «як показати» — у query-параметрах.

Кешування — збереження результату дорогої операції, щоб не обчислювати його повторно. Рівні: браузер і CDN (статика, сторінки), застосунок (Redis), база даних.

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

500 означає необроблену помилку на сервері: виняток у коді, фатальна помилка PHP, проблема з БД чи конфігурацією.

Порядок пошуку: логи застосунку (storage/logs/laravel.log), логи PHP-FPM і Nginx, сервіс моніторингу помилок (Sentry, Flare). Перевірити останні зміни й деплой, права на папки storage і bootstrap/cache, змінні оточення, доступність БД. На продакшні APP_DEBUG має бути вимкнено, щоб користувач не бачив деталей помилки.

Реляційна БД зберігає дані в таблицях, пов'язаних між собою ключами. Таблиця описує сутність (users, orders), стовпці — її атрибути з типами (email VARCHAR, created_at TIMESTAMP), рядки — окремі записи.

Запити пишуть мовою SQL. Популярні СУБД: MySQL, PostgreSQL, MariaDB, SQLite.

Первинний ключ (PRIMARY KEY) однозначно ідентифікує рядок у таблиці: унікальний і не NULL, зазвичай id. Зовнішній ключ (FOREIGN KEY) — стовпець, що посилається на первинний ключ іншої таблиці: orders.user_id → users.id.

Зовнішній ключ гарантує цілісність: не можна створити замовлення для неіснуючого користувача.

• PRIMARY KEY — головний ідентифікатор: унікальний, без NULL, один на таблицю;
• UNIQUE — унікальність значень (наприклад, email), таких обмежень може бути кілька, у більшості СУБД дозволяє NULL;
• INDEX — пришвидшує пошук і сортування, але не вимагає унікальності.

PRIMARY KEY і UNIQUE автоматично створюють індекс.

• Один до одного: користувач і його профіль;
• один до багатьох: користувач і його замовлення;
• багато до багатьох: товари й категорії, студенти й курси.

Зв'язки реалізують зовнішніми ключами, а «багато до багатьох» — через проміжну таблицю.

• Один до одного: зовнішній ключ з унікальним обмеженням — profiles.user_id UNIQUE;
• один до багатьох: зовнішній ключ на боці «багатьох» — orders.user_id;
• багато до багатьох: проміжна таблиця product_category (product_id, category_id) зі складеним первинним або унікальним ключем.

У проміжній таблиці можна зберігати додаткові дані зв'язку, наприклад role_user.assigned_at.

Нормалізація — організація таблиць так, щоб уникнути дублювання даних і аномалій при зміні. Наприклад, назву міста зберігають один раз у таблиці cities, а в users — лише city_id.

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

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

Доречно для частих важких запитів, звітів, а також коли потрібна «історична» копія (ціна товару на момент покупки). Ціна — потреба підтримувати узгодженість дубльованих даних.

• INNER JOIN повертає лише рядки, для яких є збіг в обох таблицях;
• LEFT JOIN повертає всі рядки лівої таблиці, а для відсутніх збігів — NULL у полях правої;
• RIGHT JOIN — навпаки, всі рядки правої таблиці.

Наприклад, щоб показати всіх користувачів, навіть без замовлень, потрібен users LEFT JOIN orders. RIGHT JOIN використовують рідко — його зазвичай переписують як LEFT JOIN.

JOIN об'єднує таблиці «горизонтально»: додає стовпці з іншої таблиці за умовою зв'язку. UNION — «вертикально»: склеює результати кількох запитів з однаковою кількістю й типами стовпців.

UNION прибирає дублікати, UNION ALL — ні і працює швидше.

WHERE фільтрує рядки до групування, GROUP BY групує рядки для агрегатних функцій, HAVING фільтрує вже згруповані результати.

SELECT user_id, COUNT(*) AS orders
FROM orders
WHERE status = 'paid'
GROUP BY user_id
HAVING COUNT(*) > 5;

У WHERE не можна використати агрегатну функцію — для цього і є HAVING.

Це агрегатні функції: COUNT — кількість рядків, SUM — сума значень, AVG — середнє, MIN і MAX — найменше й найбільше значення.

COUNT(*) рахує всі рядки, а COUNT(column) — лише ті, де значення не NULL. Решта функцій теж ігнорують NULL, тому AVG може відрізнятися від очікуваного.

DISTINCT прибирає повторювані рядки з результату: SELECT DISTINCT city FROM users поверне кожне місто один раз. Можна використати в агрегаті: COUNT(DISTINCT user_id).

Якщо DISTINCT доводиться додавати, щоб «прибрати дублікати після JOIN», часто це ознака помилки в умові з'єднання.

Підзапит — запит усередині іншого запиту: у WHERE, FROM або SELECT.

SELECT * FROM products
WHERE price > (SELECT AVG(price) FROM products);

Використовують для порівняння з агрегатом, перевірки існування (WHERE EXISTS (...)), побудови проміжних результатів. Часто той самий результат можна отримати через JOIN — оптимізатор сучасних СУБД добре справляється з обома варіантами, але варто перевіряти через EXPLAIN.

• DELETE видаляє рядки за умовою, працює в транзакції, запускає тригери;
• TRUNCATE швидко очищає всю таблицю і скидає автоінкремент; у MySQL не відкочується в транзакції;
• DROP видаляє саму таблицю разом зі структурою.

DELETE без WHERE видалить усі рядки — тому на продакшні такі запити виконують дуже обережно.

Транзакція — група операцій, яка виконується повністю або не виконується зовсім. Наприклад, створення замовлення й списання товару зі складу.

• Atomicity (атомарність) — усе або нічого;
• Consistency (узгодженість) — дані лишаються коректними щодо обмежень;
• Isolation (ізольованість) — паралельні транзакції не бачать проміжних змін одна одної;
• Durability (довговічність) — після коміту зміни не зникнуть навіть при збої.

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

SELECT із фільтром чи сортуванням за індексованим полем стає значно швидшим. Але INSERT, UPDATE і DELETE сповільнюються, бо треба оновлювати й індекси, а самі індекси займають місце. Тому індекси створюють під реальні запити, а не на кожне поле.

Складений індекс будується за кількома стовпцями: INDEX (status, created_at). Він працює за принципом лівого префікса: допоможе запитам з умовою за status або за status і created_at, але не запиту лише за created_at.

Зазвичай першими ставлять стовпці з умовою рівності, а потім — для діапазонів і сортування.

• Знайти повільні запити: slow query log, Laravel Telescope, Debugbar;
• подивитися план через EXPLAIN: чи використовується індекс, скільки рядків переглядається;
• перевірити, чи вибираються лише потрібні стовпці й рядки (SELECT *, відсутність LIMIT);
• пошукати N+1 у коді;
• додати або змінити індекс і порівняти час до й після.

Важливо тестувати на обсязі даних, наближеному до продакшну.

EXPLAIN показує план виконання запиту: в якому порядку читаються таблиці, які індекси використовуються, скільки рядків доведеться переглянути.

Тривожні сигнали в MySQL: type: ALL (повне сканування), великі значення rows, Using filesort і Using temporary у великих таблицях. EXPLAIN ANALYZE реально виконує запит і показує фактичний час.

Зовнішній ключ пов'язує таблиці й не дає посилатися на неіснуючі записи. Поведінку при видаленні батьківського запису задають опцією:

• ON DELETE CASCADE — видалити й пов'язані записи (позиції замовлення разом із замовленням);
• ON DELETE SET NULL — обнулити посилання;
• RESTRICT — заборонити видалення, поки є пов'язані записи.

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

TIMESTAMP зберігає момент часу в UTC і перетворює його з урахуванням часового поясу з'єднання; діапазон обмежено 1970–2038 роками. DATETIME зберігає дату й час «як є», без перетворень, з діапазоном до 9999 року.

Поширена практика — зберігати все в UTC і конвертувати в часовий пояс користувача під час виведення.

Основні: цілі (TINYINT, INT, BIGINT), дробові (DECIMAL, FLOAT, DOUBLE), рядки (VARCHAR, TEXT), дата й час (DATE, DATETIME, TIMESTAMP), JSON, ENUM, BOOLEAN (це TINYINT(1)).

FLOAT зберігає числа наближено, тому 0.1 + 0.2 не дорівнює точно 0.3. Для грошей і всього, що вимагає точності, використовують DECIMAL(10,2) або зберігають суму в копійках як ціле число.

Обидва можуть дати однаковий результат. JOIN зручний, коли потрібні стовпці з обох таблиць. Підзапит — коли друга таблиця потрібна лише для фільтрації (WHERE id IN (...) або EXISTS).

Важлива різниця: JOIN з таблицею «багатьох» може продублювати рядки, а EXISTS — ні. Щодо швидкодії, сучасні оптимізатори часто перетворюють одне на інше, тому вирішує EXPLAIN, а не загальне правило.

Блокування не дає іншим транзакціям змінювати рядок, поки поточна транзакція з ним працює. SELECT ... FOR UPDATE читає рядок і блокує його до кінця транзакції: інші транзакції, що хочуть його змінити, чекатимуть.

Використовують, коли рішення залежить від прочитаного значення: перевірити залишок на складі й зменшити його. У Laravel — ->lockForUpdate() усередині DB::transaction().

• Песимістичне блокування: SELECT ... FOR UPDATE у транзакції;
• оптимістичне блокування: стовпець version або updated_at, і оновлення лише якщо версія не змінилася (UPDATE ... WHERE id = ? AND version = ?); якщо оновлено 0 рядків — конфлікт, показуємо користувачу;
• атомарні операції: UPDATE products SET stock = stock - 1 WHERE id = ? AND stock > 0.

Вибір залежить від того, наскільки часті конфлікти.

Міграції — файли з описом змін структури БД (створити таблицю, додати колонку, індекс), які зберігаються в Git разом із кодом і застосовуються по черзі.

Завдяки ним схема однакова в усіх розробників і на серверах, а зміни можна переглянути на код-рев'ю. У Laravel: php artisan make:migration, migrate, migrate:rollback. Важливе правило: не змінювати вже застосовану на продакшні міграцію — створювати нову.

Найпростіше — список суміжності: categories (id, name, parent_id), де parent_id посилається на ту саму таблицю, а NULL — коренева категорія. Повне дерево отримують рекурсивним запитом (WITH RECURSIVE у MySQL 8 і PostgreSQL).

Альтернативи для частих запитів «усі нащадки»: materialized path (path = '1/5/12') або nested set. Для невеликих довідників дерево часто просто кешують цілком.

SQL-бази зберігають дані в таблицях зі строгою схемою, підтримують JOIN і транзакції. NoSQL мають гнучкішу модель і часто простіше масштабуються горизонтально.

Типи NoSQL: ключ-значення (Redis), документні (MongoDB), колонкові (Cassandra, ClickHouse для аналітики), графові (Neo4j), пошукові (Elasticsearch). На практиці їх поєднують: основні дані — в PostgreSQL чи MySQL, кеш і черги — в Redis, пошук — в Elasticsearch.

• Реплікація — копіювання даних з основного сервера на репліки: читання можна розподілити між ними, а репліка підстрахує при збої;
• партиціювання — поділ великої таблиці на частини в межах одного сервера, наприклад за місяцями;
• шардинг — розподіл даних між різними серверами за ключем (наприклад, user_id).

Шардинг найскладніший: JOIN і транзакції між шардами важкі, тому до нього вдаються лише тоді, коли інші способи вичерпано.

Збережена процедура — програма на SQL усередині БД, яку викликають за назвою. Тригер — код, що автоматично виконується при INSERT, UPDATE чи DELETE.

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

Laravel — найпопулярніший PHP-фреймворк для вебзастосунків і API. Переваги: зрозумілий синтаксис, Eloquent ORM, міграції, черги, події, кешування, автентифікація «з коробки», зручне тестування й велика екосистема (Horizon, Sanctum, Livewire, Filament).

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

MVC ділить застосунок на три частини: Model — дані й бізнес-правила, View — відображення, Controller — приймає запит, викликає потрібну логіку й повертає відповідь.

У Laravel: моделі Eloquent у app/Models, шаблони Blade у resources/views, контролери в app/Http/Controllers. На практиці додають ще шари — сервіси, Form Request, API Resources, — щоб контролери лишалися тонкими.

• Запит потрапляє в public/index.php, завантажується автозавантажувач і створюється застосунок;
• реєструються та запускаються сервіс-провайдери;
• HTTP-ядро пропускає запит через глобальні middleware;
• маршрутизатор знаходить маршрут і застосовує його middleware;
• викликається контролер або замикання, формується відповідь;
• відповідь проходить middleware у зворотному напрямку й надсилається клієнту.

Маршрут зв'язує URL і HTTP-метод з обробником: Route::get('/orders/{order}', [OrderController::class, 'show']);.

Вебмаршрути — у routes/web.php (з сесіями, cookies, CSRF), API — у routes/api.php (без стану, з префіксом /api; у нових версіях файл створюється командою php artisan install:api). Переглянути всі маршрути: php artisan route:list.

Відповідно до HTTP: Route::get — показати, post — створити, put/patch — оновити, delete — видалити. Route::resource('photos', PhotoController::class) створює всі сім стандартних маршрутів CRUD.

HTML-форми підтримують лише GET і POST, тому для PUT і DELETE у Blade додають @method('PUT') — Laravel підмінить метод.

Контролер приймає HTTP-запит, викликає потрібну логіку й повертає відповідь. У ньому мають бути лише «координаційні» дії: отримати перевірені дані, викликати сервіс, повернути view чи JSON.

Валідацію виносять у Form Request, бізнес-логіку — у сервіси чи action-класи, форматування відповіді — в API Resources. Так контролер лишається коротким, а логіку можна перевикористати з консольних команд і черг.

Middleware — проміжний обробник, який виконується до контролера (і може обробити відповідь після). Приклади: auth перевіряє вхід, throttle обмежує частоту запитів, verified вимагає підтвердженого email.

Middleware можна застосувати глобально, до групи маршрутів або до окремого маршруту. Власний створюють командою php artisan make:middleware.

Service Container — механізм Laravel, який створює об'єкти й автоматично підставляє їхні залежності. Якщо контролер у конструкторі просить OrderService, контейнер створить його разом із залежностями самого сервісу.

Для інтерфейсів у провайдері вказують реалізацію: $this->app->bind(PaymentGateway::class, LiqPayGateway::class). Це і є Dependency Injection: клас отримує залежності, а не створює їх сам, тому в тестах їх легко підмінити.

Service Provider — місце, де застосунок налаштовує свої сервіси під час запуску.

• register() — лише реєстрація в контейнері (bind, singleton); тут не можна звертатися до інших сервісів, бо вони можуть бути ще не зареєстровані;
• boot() — викликається після реєстрації всіх провайдерів: тут налаштовують події, макроси, правила валідації, обмеження частоти запитів.

Свої провайдери реєструють у bootstrap/providers.php.

Eloquent реалізує патерн Active Record: кожна таблиця має модель, а кожен рядок — об'єкт моделі. Модель Order за замовчуванням працює з таблицею orders.

$order = Order::where('status', 'new')->latest()->first();
$order->status = 'paid';
$order->save();

Eloquent підтримує зв'язки, приведення типів (casts), аксесори й мутатори, області запитів (scopes), події моделей і м'яке видалення.

class User extends Model {
    public function profile() { return $this->hasOne(Profile::class); }
    public function orders()  { return $this->hasMany(Order::class); }
    public function roles()   { return $this->belongsToMany(Role::class); }
}
class Order extends Model {
    public function user() { return $this->belongsTo(User::class); }
}

hasOne/hasMany — зовнішній ключ у пов'язаній таблиці (orders.user_id), belongsTo — у поточній. belongsToMany використовує проміжну таблицю role_user.

Поліморфний зв'язок дає одній моделі належати різним моделям через одну таблицю. Наприклад, коментарі можна залишати і до статей, і до відео:

// comments: id, body, commentable_id, commentable_type
class Comment extends Model {
    public function commentable() { return $this->morphTo(); }
}
class Post extends Model {
    public function comments() { return $this->morphMany(Comment::class, 'commentable'); }
}

Через Relation::enforceMorphMap() у типі зберігають короткі назви (post) замість імен класів.

Масове призначення — заповнення моделі масивом: User::create($request->all()). Небезпека: зловмисник додасть у форму поле is_admin=1, і воно збережеться.

$fillable — білий список полів, які можна заповнювати масово, $guarded — чорний список. Безпечніше використовувати $fillable і передавати лише перевірені дані: User::create($request->validated()).

• Міграції описують зміни структури БД;
• фабрики генерують моделі з тестовими даними (User::factory()->count(10)->create()), використовуючи Faker;
• сіди наповнюють базу початковими або демо-даними (php artisan db:seed).

Разом вони дають змогу будь-кому розгорнути проєкт з робочою базою однією командою php artisan migrate --seed, а фабрики — основа тестів.

• find($id) — запис за первинним ключем або null; findOrFail кине 404;
• first() — перший запис за умовами запиту або null;
• get() — колекція всіх записів за умовами;
• paginate(20) — сторінка записів плюс інформація про пагінацію для посилань.

Для великих таблиць get() без обмежень небезпечний — він завантажить усе в пам'ять.

N+1 — коли для кожного з N записів окремим запитом завантажується зв'язок: 1 запит на замовлення + 50 запитів на клієнтів.

// погано: запит у кожній ітерації
foreach (Order::all() as $order) echo $order->customer->name;
// добре: 2 запити
foreach (Order::with('customer')->get() as $order) echo $order->customer->name;

У режимі розробки варто ввімкнути Model::preventLazyLoading(), щоб такі місця кидали виняток.

Обидва фільтрують моделі за наявністю зв'язку. has('orders') — користувачі, у яких є хоча б одне замовлення, можна вказати кількість: has('orders', '>=', 3).

whereHas('orders', fn ($q) => $q->where('status', 'paid')) — додає умови до зв'язку: користувачі з оплаченими замовленнями. Протилежні — doesntHave і whereDoesntHave. Важливо: вони лише фільтрують, а не завантажують зв'язок — для цього потрібен with.

Query Builder (DB::table('orders')) будує SQL-запити через ланцюжок методів і повертає прості об'єкти, а не моделі.

Його обирають для звітів і агрегатів, масових оновлень, складних запитів, де моделі не потрібні, і коли важлива швидкодія на великих обсягах. Eloquent зручніший для звичайної роботи із сутностями, зв'язками й подіями моделей.

Найпростіше — $request->validate([...]) у контролері, але краще окремий Form Request:

class StoreOrderRequest extends FormRequest {
    public function rules(): array {
        return [
            'email' => ['required', 'email'],
            'quantity' => ['required', 'integer', 'min:1'],
        ];
    }
}

Якщо дані некоректні, Laravel поверне користувача з помилками (або JSON зі статусом 422 для API). Далі використовують лише $request->validated().

Командою php artisan make:rule UkrainianPhone створюється клас із методом validate:

class UkrainianPhone implements ValidationRule {
    public function validate(string $attribute, mixed $value, Closure $fail): void {
        if (!preg_match('/^\+380\d{9}$/', $value)) {
            $fail('Вкажіть номер у форматі +380XXXXXXXXX.');
        }
    }
}

Використання: 'phone' => ['required', new UkrainianPhone]. Для разових перевірок підходить і замикання в масиві правил.

Автентифікацію забезпечують guards (сесія для вебу, токени для API) і готові стартові набори (Breeze, Jetstream, Fortify); для API та SPA — Sanctum. Поточний користувач — auth()->user(), захист маршрутів — middleware auth.

Авторизація — через Gates (прості перевірки) і Policies (правила для моделі): $this->authorize('update', $post) або @can('update', $post) у Blade.

Gate — замикання, що перевіряє дію, не прив'язану до моделі: Gate::define('view-reports', fn (User $u) => $u->is_manager).

Policy — клас із правилами для конкретної моделі: PostPolicy з методами view, update, delete. Laravel автоматично знаходить політику за назвою моделі. Політики зручніші, коли правил багато, а Gates — для одиничних перевірок.

Додати директиву @csrf у форму Blade — вона вставить приховане поле з токеном. Middleware перевіряє токен для всіх POST, PUT, PATCH і DELETE запитів у web-маршрутах і повертає помилку 419, якщо токен відсутній або застарів.

Для AJAX-запитів токен передають у заголовку X-CSRF-TOKEN (його можна взяти з мета-тегу). Виключення з перевірки (наприклад, вебхуки платіжних систем) налаштовують окремо і захищають підписом запиту.

Job — клас із методом handle(), який виконується у фоні. Його відправляють у чергу: SendInvoice::dispatch($order). Воркер (php artisan queue:work) забирає задачі з черги (Redis, БД, SQS) і виконує.

Так повільні операції (листи, PDF, звернення до API) не затримують відповідь користувачу. На продакшні воркери запускають через Supervisor або Horizon і перезапускають після деплою командою queue:restart.

Подія повідомляє, що щось сталося (OrderPaid), а слухачі реагують на неї: надіслати лист, нарахувати бонуси, оновити статистику. Один код генерує подію, і йому не потрібно знати про всі реакції.

Це зменшує зв'язність: додати нову реакцію можна новим слухачем без зміни коду оплати. Слухачі можна виконувати в черзі (ShouldQueue). Але надмірна кількість подій ускладнює розуміння, що саме відбувається.

Через фасад Cache з драйвером Redis, Memcached, файлами чи БД:

$categories = Cache::remember('categories', now()->addHour(), function () {
    return Category::orderBy('name')->get();
});

При зміні даних кеш очищають: Cache::forget('categories'), наприклад у події моделі. Також є кешування конфігурації й маршрутів для продакшну (php artisan optimize) і атомарні блокування Cache::lock().

Laravel абстрагує роботу з файлами через «диски»: локальний, public, S3 і сумісні сховища. Код однаковий незалежно від місця зберігання:

$path = $request->file('avatar')->store('avatars', 's3');
$url = Storage::disk('s3')->url($path);

Для публічних локальних файлів виконують php artisan storage:link. Для приватних файлів видають тимчасові посилання (temporaryUrl), а не відкривають папку всім.

Обробку винятків налаштовують у bootstrap/app.php (withExceptions): можна звітувати про певні винятки в Sentry, перетворювати їх на потрібні відповіді чи ігнорувати. Для бізнес-помилок створюють власні класи винятків з методами report() і render().

Логування — через Log::info(), Log::error() з контекстом: Log::error('Оплата не пройшла', ['order_id' => $id]). Канали налаштовують у config/logging.php: щоденні файли, stderr для Docker, Slack для критичних помилок.

API Resource перетворює модель на JSON-відповідь у контрольованому форматі:

class UserResource extends JsonResource {
    public function toArray($request): array {
        return ['id' => $this->id, 'name' => $this->name, 'orders' => OrderResource::collection($this->whenLoaded('orders'))];
    }
}

Переваги: структура API не залежить від колонок БД, не «витікають» зайві поля (пароль, службові дані), зв'язки додаються лише якщо завантажені.

Laravel підтримує PHPUnit і Pest. Unit-тест перевіряє окремий клас чи функцію ізольовано, без БД і HTTP. Feature-тест перевіряє поведінку застосунку через HTTP-запит, з базою даних:

public function test_guest_cannot_create_order(): void {
    $this->postJson('/api/orders', [])->assertUnauthorized();
}

Для чистої БД між тестами використовують RefreshDatabase, для зовнішніх сервісів — фейки: Mail::fake(), Queue::fake(), Http::fake().

Команди запускають через php artisan назва: migrate, route:list, tinker, make:model. Власна — php artisan make:command ImportProducts:

class ImportProducts extends Command {
    protected $signature = 'products:import {file} {--dry-run}';
    public function handle(): int {
        $this->info('Імпорт...');
        return self::SUCCESS;
    }
}

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

Scheduler дає описати всі періодичні задачі в коді (routes/console.php), а не в crontab сервера:

Schedule::command('reports:daily')->dailyAt('07:00');
Schedule::job(new CleanupTempFiles)->hourly()->withoutOverlapping();

На сервері потрібен лише один запис cron, що щохвилини викликає php artisan schedule:run. Опція onOneServer() не дає задачі виконатися одночасно на кількох серверах.

.env містить налаштування конкретного середовища (паролі БД, ключі API) і не потрапляє в Git. Файли в config/ читають ці значення: 'key' => env('LIQPAY_KEY'), а код застосунку використовує config('services.liqpay.key').

На продакшні виконують php artisan config:cache: після цього .env не читається, і env() поза файлами конфігурації поверне null. Тому env() викликають лише в config/.

• Не завантажувати все через get(): використовувати chunk(), chunkById(), lazy() або cursor();
• вибирати лише потрібні стовпці (select);
• жадібне завантаження зв'язків через with;
• масові операції однією командою: update(), upsert(), insert();
• рахувати на боці БД (count, sum, withCount), а не через колекції;
• довгу обробку виносити в черги.

У класі job задають $tries (кількість спроб), $backoff (затримки між ними, наприклад [10, 60, 300]) і $timeout. Метод failed(Throwable $e) викликається, коли всі спроби вичерпано, — там можна сповістити команду.

Невдалі задачі потрапляють у таблицю failed_jobs: їх переглядають і повторюють командою php artisan queue:retry. Job має бути ідемпотентним, щоб повторний запуск не, наприклад, двічі списав кошти.

Composer — менеджер залежностей PHP. Він встановлює бібліотеки з Packagist потрібних версій разом із їхніми залежностями, генерує автозавантажувач класів і запускає скрипти проєкту.

Основні команди: composer require vendor/package, composer install, composer update, composer dump-autoload.

require — залежності, потрібні для роботи застосунку (фреймворк, SDK платіжної системи). require-dev — лише для розробки: PHPUnit, PHPStan, Laravel Pint, Debugbar.

На продакшні виконують composer install --no-dev --optimize-autoloader, щоб не встановлювати інструменти розробки й пришвидшити автозавантаження.

composer.json описує, які пакети потрібні й у яких діапазонах версій (^11.0). composer.lock фіксує точні встановлені версії всіх пакетів, включно із вкладеними залежностями.

Обидва файли комітять у Git: завдяки lock-файлу в усіх розробників і на сервері встановлюються однакові версії.

composer install встановлює точні версії з composer.lock — використовується при розгортанні проєкту й на сервері. composer update шукає новіші версії в межах обмежень composer.json, встановлює їх і переписує lock-файл.

update виконують свідомо, перевіряють зміни й тести, а не на продакшні. Оновити один пакет: composer update vendor/package.

PSR — рекомендації PHP-FIG, які роблять бібліотеки сумісними між собою:

• PSR-1 і PSR-12 (зараз PER Coding Style) — стиль коду;
• PSR-4 — автозавантаження класів;
• PSR-3 — інтерфейс логера;
• PSR-7 — HTTP-повідомлення, PSR-15 — обробники й middleware;
• PSR-11 — контейнер залежностей;
• PSR-6 і PSR-16 — кешування;
• PSR-18 — HTTP-клієнт.

git status              # які файли змінено
git diff                # що саме змінено
git add src/Order.php   # додати файл до коміту (git add -p — частинами)
git commit -m 'Додати перевірку залишку на складі'
git log --oneline       # історія комітів

Хороше повідомлення коміту коротко пояснює, що і навіщо змінено.

git fetch завантажує нові коміти з віддаленого репозиторію, але не змінює вашу робочу гілку — можна спершу подивитися зміни. git pull — це fetch плюс злиття (або rebase) у поточну гілку.

Багато розробників налаштовують git pull --rebase, щоб уникати зайвих merge-комітів.

Гілка — незалежна лінія розробки: git switch -c feature/order-export. В окремій гілці можна працювати над задачею, не ламаючи основний код.

Зміни потрапляють в основну гілку через pull request після код-рев'ю й проходження тестів у CI. Короткоживучі гілки на одну задачу легше переглядати й зливати без конфліктів.

Обидва переносять зміни з однієї гілки в іншу. merge створює коміт злиття й зберігає історію такою, як вона була. rebase переписує ваші коміти поверх нової бази — історія стає лінійною.

Правило: не робити rebase гілок, які вже використовують інші, бо зміниться історія. Для своєї локальної гілки rebase на свіжий main перед pull request — звична практика.

• Git позначає конфліктні місця маркерами <<<<<<<, =======, >>>>>>>;
• відкрити файли (IDE має зручний інструмент), вирішити, який код лишити, або поєднати обидва варіанти;
• прибрати маркери, перевірити, що код працює і тести проходять;
• git add для виправлених файлів і git commit (або git rebase --continue).

Якщо незрозуміло, чий код правильний, варто уточнити в автора змін.

• git restore file — скасувати незакомічені зміни у файлі (або --staged — прибрати з індексу);
• git reset — перемістити гілку на інший коміт; --hard видаляє зміни, тому для спільних гілок не підходить;
• git revert <commit> — створює новий коміт, що скасовує зміни вказаного. Безпечний для спільних гілок, бо не переписує історію.

.gitignore перелічує файли й папки, які Git не відстежує. Зазвичай це:

• .env із секретами;
• vendor/ і node_modules/ — встановлюються командами;
• логи, кеш, завантажені файли (storage/);
• зібрані фронтенд-файли;
• налаштування IDE (.idea/, .vscode/).

Якщо файл уже закомічено, .gitignore не прибере його — потрібно git rm --cached.

Docker пакує застосунок разом з оточенням (PHP потрібної версії, розширення, Nginx) у контейнер, який однаково працює на будь-якій машині.

Віртуальна машина емулює цілий комп'ютер із власною ОС — вона важка й повільно запускається. Контейнер використовує ядро хост-системи й ізолює лише процеси, тому запускається за секунди й займає менше ресурсів.

Dockerfile — інструкція зі збирання образу: базовий образ, встановлення розширень PHP, копіювання коду, команда запуску.

Docker Compose описує кілька сервісів, що працюють разом (PHP, Nginx, MySQL, Redis), у файлі compose.yaml і запускає їх однією командою docker compose up. Для Laravel готове рішення — Laravel Sail.

SSH — протокол захищеного підключення до віддаленого сервера: ssh user@server. Через нього виконують команди на сервері, переглядають логи, копіюють файли (scp, rsync).

Також SSH-ключі використовують для доступу до Git-репозиторіїв без пароля. Приватний ключ не можна нікому передавати, а вхід за паролем на серверах краще вимикати.

Процес — запущена програма з власним ідентифікатором (PID): PHP-FPM, Nginx, воркер черги. Переглянути: ps aux | grep php, top або htop; керувати сервісами — systemctl status nginx.

Логи: tail -f storage/logs/laravel.log, /var/log/nginx/error.log, journalctl -u php8.3-fpm, для контейнерів — docker logs -f container. Для пошуку — grep 'ERROR' laravel.log.

Тут немає правильної відповіді — роботодавець хоче побачити, що ви вмієте ефективно працювати з інструментами. Наприклад: PhpStorm з Laravel Idea для навігації, рефакторингу й налагодження, або VS Code з розширеннями (Intelephense, PHP Debug).

Варто згадати Xdebug для покрокового налагодження, Docker або Laravel Herd для локального оточення, лінтери й форматери (PHPStan, Pint), а також AI-асистента — і як ви перевіряєте його підказки.

function isPalindrome(string $s): bool {
    $clean = mb_strtolower(preg_replace('/[^\p{L}\p{N}]/u', '', $s));
    $chars = mb_str_split($clean);
    return $chars === array_reverse($chars);
}
isPalindrome('А роза упала на лапу Азора'); // true

Важливо використовувати mb_-функції: звичайний strrev ламає кирилицю, бо працює з байтами. Варто уточнити в інтерв'юера, чи ігнорувати пробіли й регістр.

Простий варіант — вбудовані функції: [min($nums), max($nums)]. Якщо просять без них — один прохід:

function minMax(array $nums): array {
    if ($nums === []) throw new InvalidArgumentException('Порожній масив');
    $min = $max = $nums[0];
    foreach ($nums as $n) {
        if ($n < $min) $min = $n;
        if ($n > $max) $max = $n;
    }
    return [$min, $max];
}

Складність O(n). Варто згадати обробку порожнього масиву.

$items = ['apple', 'pear', 'apple', 'plum', 'apple'];
print_r(array_count_values($items)); // ['apple' => 3, 'pear' => 1, 'plum' => 1]

// вручну
$counts = [];
foreach ($items as $item) {
    $counts[$item] = ($counts[$item] ?? 0) + 1;
}

array_count_values працює лише з рядками й цілими числами. Для сортування за частотою — arsort($counts).

$unique = array_values(array_unique([3, 1, 3, 2, 1])); // [3, 1, 2]

// вручну, зі збереженням порядку, O(n)
function unique(array $items): array {
    $seen = []; $result = [];
    foreach ($items as $item) {
        if (!isset($seen[$item])) { $seen[$item] = true; $result[] = $item; }
    }
    return $result;
}

array_values скидає ключі, які array_unique зберігає. Використання ключів масиву для перевірки швидше, ніж in_array у циклі (O(n²)).

function isPrime(int $n): bool {
    if ($n < 2) return false;
    if ($n % 2 === 0) return $n === 2;
    for ($i = 3; $i * $i <= $n; $i += 2) {
        if ($n % $i === 0) return false;
    }
    return true;
}

Достатньо перевіряти дільники до квадратного кореня з числа й лише непарні. Складність — O(√n).

function fibonacci(int $n): array {
    $result = [];
    [$a, $b] = [0, 1];
    for ($i = 0; $i < $n; $i++) {
        $result[] = $a;
        [$a, $b] = [$b, $a + $b];
    }
    return $result;
}
fibonacci(7); // [0, 1, 1, 2, 3, 5, 8]

Ітеративний варіант працює за O(n). Наївна рекурсія fib(n-1) + fib(n-2) — експоненційна, і на співбесіді варто це зазначити. Можна також показати варіант із генератором.

function sumTo(int $n): int {
    if ($n <= 0) return 0;   // базовий випадок
    return $n + sumTo($n - 1);
}
sumTo(5); // 15

Варто згадати, що на практиці краще формула $n * ($n + 1) / 2 — O(1), а глибока рекурсія при великому N може вичерпати стек.

function onlyDigits(string $s): bool {
    return ctype_digit($s);
}
// або регулярним виразом
preg_match('/^\d+$/', $s) === 1;

Пастка: is_numeric('1e5') і is_numeric('-3.5') повертають true, тому для перевірки «лише цифри» вони не підходять. ctype_digit() приймає лише рядки: передача цілого числа застаріла з PHP 8.1, тож значення з форм перевіряють як рядки.

final class User {
    public function __construct(
        private readonly int $id,
        private string $email,
    ) {
        if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
            throw new InvalidArgumentException('Некоректний email');
        }
    }
    public function getId(): int { return $this->id; }
    public function getEmail(): string { return $this->email; }
}

Варто показати сучасний синтаксис (constructor promotion, readonly) і перевірку даних у конструкторі, щоб об'єкт не міг існувати в некоректному стані.

interface PaymentGateway {
    public function charge(int $amountCents, string $orderId): string; // повертає ID транзакції
}
final class LiqPayGateway implements PaymentGateway {
    public function charge(int $amountCents, string $orderId): string { /* виклик API LiqPay */ return 'lp_123'; }
}
final class FakeGateway implements PaymentGateway {
    public array $charges = [];
    public function charge(int $amountCents, string $orderId): string {
        $this->charges[] = [$amountCents, $orderId];
        return 'fake_' . count($this->charges);
    }
}

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

final class CheckoutService {
    public function __construct(private PaymentGateway $gateway) {}
    public function pay(Order $order): string {
        return $this->gateway->charge($order->totalCents, $order->id);
    }
}
// у робочому коді
$service = new CheckoutService(new LiqPayGateway());
// у тесті
$service = new CheckoutService(new FakeGateway());

Сервіс не знає, яка платіжна система використовується. У Laravel реалізацію для інтерфейсу вказують у сервіс-провайдері, і контейнер передасть її автоматично.

Виведе 7 5 7.

• $b = $a++ — спочатку $b отримує поточне значення 5, потім $a стає 6;
• $c = ++$a — спочатку $a збільшується до 7, потім $c отримує 7.

bool(true) і bool(false).

== порівнює з приведенням типів: числовий рядок "10" перетворюється на число 10, і значення рівні. === порівнює ще й типи: string не дорівнює int.

Якщо в книги може бути кілька авторів, потрібна проміжна таблиця:

CREATE TABLE authors (id BIGINT PRIMARY KEY, name VARCHAR(255) NOT NULL);
CREATE TABLE books (id BIGINT PRIMARY KEY, title VARCHAR(255) NOT NULL);
CREATE TABLE author_book (
  author_id BIGINT REFERENCES authors(id),
  book_id BIGINT REFERENCES books(id),
  PRIMARY KEY (author_id, book_id)
);

SELECT a.id, a.name, COUNT(ab.book_id) AS books_count
FROM authors a
LEFT JOIN author_book ab ON ab.author_id = a.id
GROUP BY a.id, a.name;

LEFT JOIN лишає авторів без книг, а COUNT(ab.book_id) дасть для них 0 (на відміну від COUNT(*), який порахував би 1).

SELECT DISTINCT salary
FROM employees
ORDER BY salary DESC
LIMIT 1 OFFSET 1;

-- або без LIMIT
SELECT MAX(salary) FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

DISTINCT важливий: якщо два працівники мають однаковий найбільший оклад, без нього повернеться той самий максимум. Варіант із MAX поверне NULL, якщо другого окладу немає. Для N-го значення зручні віконні функції DENSE_RANK().

SELECT c.*
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

-- або
SELECT * FROM customers c
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);

Варіант NOT IN (SELECT customer_id FROM orders) небезпечний: якщо в підзапиті трапиться NULL, результат буде порожнім. У Laravel — Customer::doesntHave('orders')->get().

SELECT p.id, p.name, SUM(oi.quantity) AS sold
FROM order_items oi
JOIN products p ON p.id = oi.product_id
JOIN orders o ON o.id = oi.order_id
WHERE o.status = 'paid'
GROUP BY p.id, p.name
ORDER BY sold DESC
LIMIT 3;

Варто уточнити, що означає «популярність»: кількість одиниць (SUM(quantity)) чи кількість замовлень (COUNT(DISTINCT order_id)), і враховувати лише оплачені замовлення.

• Відтворити запит і виміряти час на даних продакшн-обсягу;
• подивитися EXPLAIN: чи є повне сканування, скільки рядків переглядається, чи потрібне сортування на диску;
• додати індекс під умови WHERE, JOIN і ORDER BY (складений, з правильним порядком стовпців);
• вибирати лише потрібні стовпці, додати LIMIT, замінити OFFSET на keyset-пагінацію;
• перевірити, чи не обгорнуте поле функцією (WHERE DATE(created_at) = ... не використає індекс);
• для важких звітів — кеш, агрегатні таблиці або репліка для читання.

Після змін — повторно виміряти й порівняти.

$order = DB::transaction(function () use ($userId, $productId, $qty) {
    $product = Product::lockForUpdate()->findOrFail($productId);
    if ($product->stock < $qty) {
        throw new OutOfStockException();
    }
    $product->decrement('stock', $qty);
    $order = Order::create(['user_id' => $userId, 'status' => 'new']);
    $order->items()->create(['product_id' => $productId, 'quantity' => $qty, 'price' => $product->price]);
    return $order;
});

lockForUpdate не дає двом запитам одночасно продати останній товар. Якщо будь-який крок кине виняток, транзакція відкотиться повністю.

// routes/api.php
Route::get('/users', [UserController::class, 'index'])->middleware('auth:sanctum');

// app/Http/Controllers/UserController.php
class UserController extends Controller {
    public function index(Request $request) {
        $users = User::query()
            ->when($request->query('search'), fn ($q, $s) => $q->where('name', 'like', "%{$s}%"))
            ->orderBy('name')
            ->paginate(20);
        return UserResource::collection($users);
    }
}

Важливі деталі: захист маршруту, пагінація замість повного списку і API Resource, щоб не віддати пароль та службові поля.

class RegisterRequest extends FormRequest {
    public function rules(): array {
        return [
            'name' => ['required', 'string', 'max:100'],
            'email' => ['required', 'email', 'max:255', 'unique:users,email'],
            'password' => ['required', 'confirmed', Password::min(8)->letters()->numbers()],
        ];
    }
}

public function store(RegisterRequest $request) {
    $user = User::create([...$request->validated(), 'password' => Hash::make($request->password)]);
    Auth::login($user);
    return redirect('/dashboard');
}

confirmed вимагає поле password_confirmation. Пароль зберігаємо лише як хеш.

$products = Product::query()
    ->with('category:id,name')
    ->select(['id', 'name', 'price', 'category_id'])
    ->latest()
    ->paginate(24);

with завантажить усі категорії одним додатковим запитом. Синтаксис category:id,name обмежує стовпці, але category_id у вибірці товарів обов'язковий, інакше зв'язок не знайдеться.

// міграція
Schema::create('role_user', function (Blueprint $t) {
    $t->foreignId('user_id')->constrained()->cascadeOnDelete();
    $t->foreignId('role_id')->constrained()->cascadeOnDelete();
    $t->primary(['user_id', 'role_id']);
});

class User extends Model {
    public function roles() { return $this->belongsToMany(Role::class)->withTimestamps(); }
}

$user->roles()->attach($roleId);
$user->roles()->sync([1, 3]);   // лишити тільки ці ролі
$user->roles()->detach($roleId);

Для таймстемпів у проміжній таблиці додають $t->timestamps().

class SendWelcomeEmail implements ShouldQueue {
    use Queueable;
    public int $tries = 3;
    public array $backoff = [30, 120];

    public function __construct(public User $user) {}

    public function handle(): void {
        Mail::to($this->user)->send(new WelcomeMail($this->user));
    }
}

SendWelcomeEmail::dispatch($user)->afterCommit();

afterCommit гарантує, що задача піде в чергу лише після збереження користувача в БД. Модель серіалізується за ID і завантажується заново у воркері.

class ProductIndexTest extends TestCase {
    use RefreshDatabase;

    public function test_it_returns_paginated_products(): void {
        Product::factory()->count(3)->create();

        $this->getJson('/api/products')
            ->assertOk()
            ->assertJsonCount(3, 'data')
            ->assertJsonStructure(['data' => [['id', 'name', 'price']], 'meta']);
    }
}

Добре додати тести на порожній список, фільтри й на те, що прихованих полів у відповіді немає.

Звичайний paginate() використовує OFFSET і рахує загальну кількість через COUNT(*) — на далеких сторінках і великих таблицях це повільно.

• simplePaginate() — без підрахунку загальної кількості (лише «вперед/назад»);
• cursorPaginate() — keyset-пагінація за індексованим полем (WHERE id > ?), стабільно швидка на будь-якій сторінці;
• індекс під сортування, вибірка лише потрібних стовпців, кешування кількості.

Для нескінченної прокрутки та API найкраще підходить курсорна пагінація.

$request->validate([
    'document' => ['required', 'file', 'mimes:pdf,jpg,png', 'max:5120'], // до 5 МБ
]);
$path = $request->file('document')->store('documents', 's3');

Правило mimes перевіряє реальний вміст файлу, а не лише розширення. Ім'я файлу генерується автоматично — не варто зберігати під назвою від користувача. Приватні документи зберігають поза публічною папкою й видають через тимчасові посилання. Також варто обмежити розмір у налаштуваннях PHP і Nginx.

• Подивитися storage/logs/laravel.log і логи Nginx / PHP-FPM;
• перевірити .env на сервері: чи є APP_KEY, доступи до БД, чи не забули нові змінні;
• права на запис для storage і bootstrap/cache;
• чи виконано composer install --no-dev, міграції, php artisan optimize:clear і повторно optimize;
• версію PHP і розширення на сервері;
• чи перезапущені PHP-FPM і воркери черг.

Якщо причина незрозуміла, а помилка критична — відкотити реліз і розбиратися спокійно.

Головне — вважати ключ скомпрометованим, навіть якщо коміт ще не запушено:

• одразу відкликати й перевипустити ключ у сервісі;
• повідомити тімліда або відповідального за безпеку;
• перенести секрет у .env і додати файл у .gitignore;
• якщо коміт не запушено — виправити історію (git commit --amend або interactive rebase); якщо запушено — очистити історію (git filter-repo) лише за домовленістю з командою;
• перевірити логи сервісу на підозріле використання.

Просто видалити ключ наступним комітом недостатньо — він лишається в історії.

• Відтворити помилку і подивитися лог та stack trace;
• переглянути diff злиття, особливо місця, де були конфлікти, — часто зміни вирішено неправильно;
• запустити тести; якщо тест для endpoint падає — він підкаже місце;
• якщо причина неочевидна — git bisect, щоб знайти коміт, після якого все зламалося;
• перевірити міграції, конфігурацію й залежності, які змінила інша гілка.

Після виправлення — додати тест, який зловив би цю проблему.

Не вигадувати вимоги самостійно, а уточнити: сформулювати конкретні питання до менеджера чи замовника, запропонувати варіанти рішення з наслідками кожного й зафіксувати домовленості письмово в задачі.

Якщо відповіді доведеться чекати — почати з частини, яка зрозуміла, і заздалегідь назвати припущення. Роботодавець хоче побачити, що ви не мовчите тиждень і не робите «як здалося».

• Логи застосунку й сервера: точний текст помилки;
• відмінності оточення: версія PHP та розширення, змінні .env, кешована конфігурація;
• чи виконано міграції й composer install на сервері;
• права доступу до файлів, регістр у назвах файлів (Linux чутливий до регістру, macOS і Windows — ні);
• мережеві доступи до БД, Redis і зовнішніх API, налаштування firewall;
• чи запущені воркери черг і cron для Scheduler.

Docker допомагає зменшити різницю між локальним і серверним оточенням.

• Розібратися, як працює наявний код, і зафіксувати поточну поведінку тестами високого рівня (feature-тести через HTTP);
• виділити залежності (зовнішні API, час, БД) у класи, які можна підмінити;
• невеликими кроками винести логіку з контролера в сервіс, запускаючи тести після кожного кроку;
• нову функцію писати вже в тестованому вигляді.

Великий рефакторинг без узгодження з командою не варто починати — краще домовитися про обсяг.

Нотація «O велике» показує, як зростає час роботи зі збільшенням обсягу даних:

• O(1) — сталий час: доступ до елемента масиву за ключем;
• O(log n) — бінарний пошук, пошук в індексі БД;
• O(n) — один прохід по масиву;
• O(n²) — вкладені цикли по тих самих даних, наприклад in_array усередині foreach.

Для 100 000 елементів різниця між O(n) і O(n²) — це мілісекунди проти хвилин.

Порушення Single Responsibility — «товстий» метод контролера:

public function store(Request $r) {
    // валідація, розрахунок знижки, збереження, оплата, лист, лог — усе тут
}

Його важко тестувати й змінювати: зміна тексту листа зачіпає код оплати. Виправлення — Form Request для валідації, DiscountCalculator, CheckoutService, подія OrderPlaced зі слухачем для листа.

Порушення Open/Closed — switch ($type) для кожного способу доставки: новий спосіб вимагає змінювати наявний код замість додавання нового класу.

Ідемпотентний запит при повторному виконанні дає той самий результат, що й при першому. GET, PUT, DELETE ідемпотентні, POST — ні.

Це важливо, бо мережа ненадійна: клієнт може не отримати відповідь і повторити запит. Для платежів і створення замовлень використовують ключ ідемпотентності: клієнт надсилає унікальний Idempotency-Key, а сервер, отримавши той самий ключ удруге, повертає збережений результат замість повторної операції.

Потрібен захист на кількох рівнях:

• у браузері — блокувати кнопку після першого натискання;
• на сервері — ключ ідемпотентності або унікальний токен форми, збережений разом із замовленням;
• атомарне блокування Cache::lock('checkout:'.$userId, 10) на час обробки;
• унікальний індекс у БД як останній рубіж.

Лише фронтенд-захисту недостатньо: запит можна повторити з мережевої вкладки або через повільну мережу.

• Кеш у пам'яті процесу (статична змінна, once() у Laravel) живе лише в межах одного запиту чи процесу — найшвидший, але не спільний;
• Redis — окремий сервіс, спільний для всіх серверів і воркерів, переживає запити; підходить для даних застосунку, сесій, черг, блокувань;
• кеш браузера й CDN керується HTTP-заголовками (Cache-Control, ETag) і зберігає статику та відповіді на боці клієнта — запит до сервера взагалі не надходить.

Race condition — помилка, коли результат залежить від того, в якому порядку виконаються паралельні операції.

Приклад: на складі лишився 1 товар. Два запити одночасно читають stock = 1, обидва перевіряють «достатньо», обидва зменшують — продано 2 товари, залишок -1.

Рішення: атомарний UPDATE ... SET stock = stock - 1 WHERE stock > 0 і перевірка кількості змінених рядків, або lockForUpdate() у транзакції, або Cache::lock().

• Швидкість відповіді: користувач не чекає, поки надішлеться лист чи згенерується PDF;
• надійність: якщо зовнішній сервіс недоступний, задача повториться пізніше, а не покаже користувачу помилку;
• контроль навантаження: важкі задачі виконуються рівномірно воркерами, а не всі одночасно;
• таймаути: HTTP-запит обмежений у часі, а фонова задача може працювати довше.

Але черга додає складності: потрібні воркери, моніторинг і ідемпотентні задачі.

Паролі зберігають лише як хеш, отриманий повільною адаптивною функцією: password_hash($password, PASSWORD_DEFAULT) (bcrypt) або Argon2id; у Laravel — Hash::make(). Перевірка — password_verify().

MD5 і SHA-1 дуже швидкі: сучасна відеокарта перебирає мільярди варіантів за секунду, а для популярних паролів існують готові таблиці. Bcrypt і Argon2 навмисно повільні й автоматично додають сіль.

Історія Git зберігає все назавжди: навіть видалений ключ лишається в старих комітах. Репозиторій копіюють на ноутбуки розробників, у CI, сторонні сервіси; приватний репозиторій може стати публічним або витекти.

Боти постійно сканують GitHub на ключі хмарних сервісів і використовують їх за лічені хвилини. Секрети зберігають у .env поза Git і в менеджерах секретів, а в репозиторії лишають лише .env.example.

Код-рев'ю — перевірка змін колегою перед злиттям. Мета — знайти помилки, поширити знання про код і підтримувати спільні стандарти.

На що дивляться: чи виконує код задачу, граничні випадки й обробку помилок, безпеку (валідація, SQL-ін'єкції, права доступу), N+1 і продуктивність, зрозумілість назв, наявність тестів. Коментарі пишуть конкретно й доброзичливо, з поясненням чому, а не «переписати».

• Unit-тест перевіряє один клас чи функцію ізольовано, залежності підмінено — швидкий;
• інтеграційний тест перевіряє взаємодію кількох частин із реальною інфраструктурою: репозиторій із справжньою БД, клієнт зовнішнього API проти тестового сервера;
• feature-тест (у Laravel) перевіряє сценарій через HTTP-запит: маршрут, middleware, валідацію, БД і відповідь.

Поширений підхід — багато швидких unit-тестів і основні сценарії покриті feature-тестами.

Моноліт — один застосунок з однією кодовою базою, який розгортається цілком. Його простіше розробляти, тестувати й розгортати, тому для більшості проєктів це правильний старт.

Мікросервіси — кілька незалежних застосунків, кожен зі своєю відповідальністю й даними, які спілкуються через API чи черги. Вони дають незалежні релізи й масштабування окремих частин, але додають складність: мережеві збої, розподілені дані, моніторинг. Їх обирають, коли розмір команди й навантаження справді цього вимагають.

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

Його не можна повністю уникнути — інколи свідомий борг заради швидкого запуску виправданий. Важливо фіксувати його в задачах, пояснювати бізнесу вплив («кожна зміна в оплаті займає вдвічі більше часу»), виділяти час на виправлення й залишати код трохи кращим після кожної задачі.

• Автоматичні тести локально й у CI перед злиттям;
• статичний аналіз (PHPStan) і форматування (Pint);
• ручна перевірка сценаріїв, яких торкнулися зміни, включно з граничними випадками;
• перегляд diff перед комітом і код-рев'ю колегою;
• після релізу — моніторинг помилок (Sentry) і логів.

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

Це поведінкове питання: відповідь має бути власною історією за схемою «ситуація — дії — результат». Наприклад:

«Сторінка замовлень в адмінці завантажувалася 8 секунд. Я ввімкнув Debugbar і побачив понад 300 SQL-запитів — класична N+1 при виведенні клієнтів і товарів. Додав with() для зв'язків і індекс на orders.status. Кількість запитів зменшилася до 4, сторінка відкривається менше ніж за секунду. Щоб проблема не повернулася, увімкнув preventLazyLoading() у режимі розробки».

Важливо показати хід думок і як ви перевірили результат, а не лише фінальне рішення.

N+1 виникає, коли для списку з N записів виконується ще N окремих запитів для пов'язаних даних. Наприклад, виводимо 50 замовлень і для кожного окремо запитуємо клієнта — 51 запит замість двох.

Виправляють жадібним завантаженням: Order::with('customer')->get(). Виявити допомагають Laravel Debugbar, Telescope або Model::preventLazyLoading() у режимі розробки — тоді лінивий запит кидає виняток.

Service Container — це контейнер залежностей: він знає, як створювати об'єкти, і автоматично передає їх у конструктори через type-hint. Якщо клас залежить від інтерфейсу, у сервіс-провайдері вказують, яку реалізацію підставити: $this->app->bind(PaymentGateway::class, StripeGateway::class).

bind створює новий об'єкт щоразу, singleton — один на запит (або на весь процес у Octane). Це спрощує тестування: у тесті реалізацію можна замінити на фейк.

Черги виносять повільні завдання з HTTP-запиту: відправку листів, генерацію PDF, звернення до зовнішніх API. Користувач отримує відповідь одразу, а worker обробляє задачу у фоні.

Для надійності задають $tries і backoff, роблять job ідемпотентним (повторний запуск не створює дублікатів), а невдалі задачі потрапляють у failed_jobs. Для моніторингу використовують Horizon, а для ланцюжків — Bus::chain чи Bus::batch.

Сильна відповідь — з прикладами з власного коду:

• enum замість констант для статусів замовлення;
• readonly властивості й класи для DTO та value objects;
• match замість громіздких switch;
• named arguments і constructor property promotion;
• у PHP 8.4 — property hooks та асиметрична видимість (public private(set)), а в PHP 8.5 — pipe-оператор |>.

Варто згадати, як ви оновлювали проєкт на нову версію: Rector, PHPStan і тести допомагають зробити це безпечно.

Почати варто з вимірювань: де вузьке місце — БД, CPU чи зовнішні сервіси. Далі типові кроки:

• кешування каталогу й сторінок (Redis, HTTP-кеш, CDN);
• черги для всього, що не обов'язково робити синхронно;
• репліки БД для читання, індекси, а для складу — атомарні операції або блокування, щоб не продати більше, ніж є;
• горизонтальне масштабування застосунку без стану (сесії в Redis), Octane чи RoadRunner для швидкодії;
• rate limiting і деградація некритичних функцій.

Обов'язково — навантажувальне тестування (k6) до розпродажу й метрики (OpenTelemetry, Grafana) під час нього.

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

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

У 2026 році це вже стандартне питання. Добра відповідь показує баланс: AI-асистенти (Copilot, Cursor, Claude) пришвидшують шаблонний код, тести, міграції й розбір чужого коду, але відповідальність за результат лишається на розробнику.

Контроль якості — ті самі правила, що й для людського коду: обов'язкове код-рев'ю, тести, статичний аналіз (PHPStan на високому рівні), заборона передавати в зовнішні моделі секрети й персональні дані клієнтів. Корисно навести приклад, де AI помилився і як ви це виявили.

Пряма зміна колонки може заблокувати таблицю на хвилини. Підхід expand–contract:

• додати нову колонку чи таблицю, не чіпаючи стару;
• писати дані в обидва місця, а старі записи переносити фоновою задачею частинами;
• переключити читання на нову структуру й перевірити;
• видалити стару колонку окремим релізом.

Для MySQL допомагають онлайн-DDL (ALGORITHM=INPLACE), gh-ost або pt-online-schema-change. Важливо мати план відкату й перевірити міграцію на копії продакшн-даних.