Словник веб-розробника

Магічні методи — спеціальні методи з подвійним підкресленням (__method), що PHP викликає автоматично при певних операціях над об'єктом. Дозволяють перевизначити стандартну поведінку класу.Найважливіші__construct() — викликається при new ClassName()__destruct() — при знищенні об'єкта__get($name) / __set($name, $value) — доступ до неіснуючих або захищених властивостей__call($name, $args) — виклик неіснуючого методу__toString() — конвертація об'єкта в рядок__invoke() — виклик об'єкта як функції: $obj()__clone() — після клонування об'єкта__serialize() / __unserialize() — контроль серіалізаціїЗастереженняМагічні методи повільніші за звичайні. __get/__set ускладнюють статичний аналіз — IDE не «бачить» властивостей. Використовуйте там, де справді потрібна динаміка.

Мемоізація — оптимізація: результати дорогих функцій кешуються по аргументах і повертаються без повторного обчислення при тому самому вході. Підвид кешування, де ключ — аргументи функції. Приклад function memoize(callable $fn): Closure { $cache = []; return function() use ($fn, &$cache) { $key = serialize(func_get_args()); if (!isset($cache[$key])) { $cache[$key] = $fn(...func_get_args()); } return $cache[$key]; }; } $expensiveFib = memoize(function(int $n) use (&$expensiveFib): int { return $n

Монорепозиторій — один Git-репозиторій для кількох проєктів або пакетів. Весь код (frontend, backend, shared libs, мобільні застосунки) зберігається разом. Протилежність — polyrepo (окремий репозиторій для кожного сервісу).ПеревагиЄдині зміни в shared-коді одразу видно в усіх проєктах — немає проблеми «якої версії бібліотеки»Атомарні коміти: одна зміна API і відповідний рефакторинг усіх споживачів — в одному PRЄдині CI/CD, linting, тести — менше конфігураціїНедолікиПовільніший CI без інструментів кешування (потрібно запускати тільки змінені частини)Складніше управління доступом до різних проєктівІнструментиNx (JavaScript/TypeScript), Turborepo (JS), Bazel (Google, multi-language). Великі монорепо: Google, Meta, Microsoft тримають весь код в одному репозиторії.

Моніторинг — відстеження стану системи в реальному часі та сповіщення при відхиленнях. Observability — ширша концепція: здатність зрозуміти чому система поводиться так, а не лише що відбувається.Три стовпи observabilityMetrics — числові показники за час: RPS, latency p99, error rate, CPU. Prometheus + Grafana — стандартLogs — структуровані записи подій. Централізований збір: ELK Stack (Elasticsearch, Logstash, Kibana), LokiTraces — відстеження шляху запиту через кілька сервісів. Jaeger, Zipkin, OpenTelemetryЗолоті сигнали (Google SRE)Latency, Traffic, Errors, Saturation — чотири метрики, що описують здоров'я будь-якого сервісу. Алертинг на них покриє 80% інцидентів.

Мутаційне тестування — метод оцінки якості тестів: інструмент автоматично вносить дрібні зміни (мутації) в код і перевіряє, чи виявляють їх існуючі тести. Якщо мутований код проходить тести — тести недостатньо якісні. Типові мутації + → -, > → >=, === → !== Видалення умови: if ($x > 0) → if (true) Зміна повернення: return true → return false Метрика: Mutation Score MS = вбиті мутанти / загальна кількість мутантів * 100%. MS 80%+ вважається хорошим результатом. Відрізняється від code coverage: 100% coverage не гарантує виявлення логічних помилок. Інструменти PHP: Infection. JavaScript: Stryker. Java: PIT. Вартість Мутаційне тестування повільне — запускає тести для кожного мутанта. Зазвичай застосовують на критичних частинах коду, а не по всьому проєкту.

Міграція — версія схеми бази даних у вигляді коду. Замість того щоб вручну виконувати SQL ALTER TABLE на кожному сервері, міграції зберігаються в репозиторії і застосовуються однією командою на будь-якому оточенні.Навіщо це потрібноМіграції вирішують проблему синхронізації схеми БД між локальним середовищем, staging і продакшном. Нова міграція в коді — це нова зміна на всіх серверах після виконання команди застосування міграцій.Типова структураКожна міграція має два методи: up() — вносить зміни в схему, down() — скасовує їх (rollback). Ім'я файлу містить timestamp, щоб гарантувати порядок застосування.Важливі правилаНіколи не редагуйте вже застосовану міграцію — створіть новуЗберігайте міграції в системі контролю версій разом з кодомДля безпечного деплою на великі таблиці використовуйте інструменти типу gh-ost або pt-online-schema-change

Мікросервіси — архітектурний підхід, при якому застосунок розбивається на невеликі незалежні сервіси, кожен з яких відповідає за одну бізнес-функцію, має свою базу даних і розгортається окремо.Монолітна vs мікросервісна архітектураМоноліт — один застосунок, одна БД, один деплой. Простий у розробці на початку, але важко масштабувати окремі частини і один баг може покласти всю систему. Мікросервіси — складніше, але кожен сервіс можна масштабувати, деплоїти і розробляти незалежно.Комунікація між сервісамиСинхронна — HTTP REST або gRPC (відповідь потрібна одразу)Асинхронна — message broker (RabbitMQ, Kafka): сервіс надсилає подію і не чекаєКоли варто розглядатиМікросервіси виправдані при значному навантаженні та великій команді. Для стартапу або невеликого продукту — добре побудований моноліт простіший, дешевший і швидший у розробці.

Мікрофронтенди — архітектурний підхід, що переносить ідеї мікросервісів на фронтенд: застосунок розбивається на незалежні частини, кожна з яких розробляється, тестується і деплоїться окремою командою. Мотивація Великий монолітний SPA стає важким: 5-10 команд правлять один репозиторій, деплой блокується, конфлікти залежностей. Мікрофронтенди дозволяють командам працювати незалежно. Підходи до інтеграції Build-time integration — npm-пакети. Просто, але деплой усе одно пов'язаний Runtime via iframe — ізоляція, але обмежена взаємодія Web Components — нативна браузерна ізоляція Module Federation (Webpack 5) — найпопулярніший. Динамічний імпорт між окремими збірками Проблеми Дублювання коду (кілька версій React) Узгоджений UX між командами Складніша відлагодження Виправданий для великих продуктів (>5 команд). Для малих — зайве ускладнення.