Словарь веб-разработчика

Магические методы — специальные методы с двойным подчёркиванием (__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]; }; } $fib = memoize(function(int $n) use (&$fib): int { return $n

Миграция — версия схемы базы данных в виде кода. Вместо того чтобы вручную выполнять 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+ команд). Для малых — лишнее усложнение.

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

Монорепозиторий — один 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 хранят весь код в одном репозитории.

Мутационное тестирование — метод оценки качества тестов: инструмент автоматически вносит мелкие изменения (мутации) в код и проверяет, выявляют ли их существующие тесты. Если мутированный код проходит тесты — тесты недостаточно качественные. Типичные мутации + → -, > → >=, === → !== Удаление условия: 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. Стоимость Мутационное тестирование медленное — запускает тесты для каждого мутанта. Обычно применяют на критических частях кода, а не по всему проекту.