Версия API защищает клиентов от внезапных изменений, но добавляет маршруты, тесты, документацию и поддержку старых контрактов. Сравниваем URL, заголовки и медиатипы и разбираем, где каждый подход начинает дорого обходиться.
Пользователь нажал «Оплатить» дважды, клиент повторил запрос после тайм-аута, а платёжный шлюз уже списал деньги. Идемпотентность помогает пережить такие повторы без двойного списания — но только если правильно выбрать ключ и хранить состояние операции.
Хороший лог помогает восстановить ход события, плохой превращает поиск причины в перебор миллионов строк. Разбираем, какие поля и события нужны приложению, какие данные опасно писать и как не утонуть в шуме.
Если каждый модуль сообщает об ошибках по-своему, сбой трудно найти, а клиенту легко раскрыть лишнее. Разбираем, как договориться о типах ошибок, границах обработки, логах и повторах без привязки к конкретному языку.
Разделение на контроллер, сервис и репозиторий помогает не превратить обработчик HTTP-запроса в комбайн из SQL, бизнес-правил и сериализации. Разбираем границы слоёв, цену лишней абстракции и признаки плохой архитектуры.
Микромодуль помогает ограничить изменения одной частью системы, но легко превращается в папку из двух файлов и десятки лишних связей. Разбираем границы, цену дробления и ошибки, которые усложняют поддержку.
Микромодуль помогает разделить код без преждевременного перехода на микросервисы. Сравниваем функцию, пакет, библиотеку и отдельный сервис, чтобы выбрать границу без лишней сложности.
DRY не требует превращать каждое совпадение строк в общую функцию. Разбираем, когда дублирование действительно опасно, когда оно дешевле абстракции и как выбрать подход для конкретного проекта.
Два одинаковых фрагмента кода ещё не означают, что их нужно объединить. Разбираем, как отличить копию одного бизнес-правила от похожей логики, которая будет меняться по-разному, и когда рефакторинг окупится.
Один класс оформляет заказ, считает скидку, списывает деньги и отправляет письмо — пока проект маленький, это незаметно. Разбираем, как поэтапно разделить такую систему по SOLID на TypeScript 5.x и не превратить код в лес интерфейсов.
SOLID не требует превращать каждый класс в интерфейс. На примере оформления заказа в PHP 8.3 разбираем, где принципы действительно снижают цену изменений, а где добавляют лишние слои и усложняют код.
Пять принципов SOLID полезны не как набор лозунгов, а как способ найти дорогие изменения до релиза. Разбираем PHP 8.3 на примере заказа, оплаты и скидок и собираем чек-лист для ревью.