День 2552. #BestPractices
Чему 9 Лет Работы в Разработке Научили Меня о «Лучших Практиках»

Автор оригинала: Luthfi Noviandi

Долгое время я считал, что, если достаточно строго следовать лучшим практикам, всё само собой заработает. Поэтому я делал всё «правильно». Чистая архитектура. Микросервисы. Повторные попытки. Паттерны поверх паттернов. Код отлично выглядел на ревью. Диаграммы были чистыми. Это ощущалось как качественная разработка. А потом всё запускалось в продакшен…

Небольшие изменения занимали больше времени, чем следовало. Исправление одной ошибки означало проверку множества сервисов и логов, разбросанных по разным инструментам. Когда что-то ломалось, это не было явно. Оно ломалось тихо, а повторные попытки приводили его в ещё худшее состояние. В конце концов, я осознал неприятную правду:
Система была хрупкой не потому, что мы игнорировали лучшие практики.
Она была хрупкой потому, что мы следовали им слишком буквально.

После почти девяти лет работы над бэкенд-системами, включая платёжные системы, событийно-ориентированные потоки, мультитенантные платформы и т.п. я понял, что лучшие практики не ошибочны. Они просто неполны. Они написаны для конкретного контекста, и проблемы начинаются, когда мы относимся к ним как к универсальным правилам.

Лучшие практики, которым я больше не следую слепо
1. «Всегда используйте микросервисы»
Микросервисы решают не столько технические проблемы, сколько организационные. Без команды и масштаба, оправдывающих их использование, они в основном увеличивают операционные издержки. Теперь я по умолчанию использую модульный монолит и разделяю сервисы только тогда, когда есть реальная необходимость в этом.

2. «Проектируйте с учётом масштабируемости с самого начала»
Большинство систем выходят из строя не потому, что не могут масштабироваться. Они выходят из строя потому, что их сложно изменять. Теперь я изначально проектирую с учетом ясности поддержки. Масштабирование позже обычно проще, чем распутывание избыточного проектирования на ранних этапах.

3. «Повторные попытки делают системы отказоустойчивыми»
Повторные попытки могут помочь, но они также могут превратить небольшие отказы в полномасштабные сбои. Без лимитов, прерываний и прозрачности повторные попытки — это просто усилители сбоев.

4. «Гарантии выполнения ровно-один-раз спасут нас»
Гарантии инфраструктуры не защищают от бизнес-ошибок. Если ваша логика не идемпотентна, доставка ровно один раз не спасёт вас от двойной обработки или двойной оплаты.

5. «Чистая архитектура повсюду»
Чистая архитектура полезна до тех пор, пока не превращается в лабиринт. Если абстракции мешают пониманию больше, чем помогают, они вредны.

Практики, которым стоит следовать всегда
Некоторые уроки слишком дорого переучивать:
1. Идемпотентность для всего критически важного.
2. Чёткое определение владельца данных.
3. Сначала наблюдаемость потом оптимизации.
4. Явные сбои вместо скрытых повторных попыток.
Эти практики не делают системы элегантными. Они делают их надёжными.

Большинство лучших практик — это реакция на прошлые проблемы. Они предполагают ограничения, команды и масштаб, которых у вас может не быть. Это не делает их плохими. Это означает, что им нужен контекст. Лучшие практики — это отправная точка, а не контракт.

Итого
Я по-прежнему забочусь о качественной разработке. Просто теперь я больше доверяю опыту, чем правилам. Лучшая практика, на которую я полагаюсь сегодня, проста: понимайте свой контекст лучше, чем применяемый вами паттерн. Всё остальное подлежит обсуждению.

Источник: https://blog.stackademic.com/what-9-years-of-backend-engineering-taught-me-about-best-practices-53e8a6e2d21d