Техлид: Стратегия Архитектуры

Мы запустили новый сервис. Он быстрый, надежный, команда получила за него премии, и счастливо выдохнула.

Проходит год

В сервисе 20 новых фич, из прошлой команды осталось пару челов, код начал напоминать спагетти, при этом существует миллион тестов. Узнали? И вот что: работа не заканчивается после релиза, она только начинается. Самая идеальная архитектура как минимум обречена на деградацию

Наша задача планировать долгосрочно. Это как в играх-стратегиях, где нужно управлять развитием системы, избегать ее отставания и при малейшей возможности адаптировать к новым проблемам.

1️⃣Технический долг

В реальности техдолг - финансовый инструмент. Иногда мы берем его осознанно и делаем костыли, чтобы быстрее выпустить MVP, и в то же время он накапливается незаметно через устаревание либок или плохой дизайн

Ну типа зачем бороться с техдолгом, когда им можно правильно управлять

Что с ним можно делать я подробно писал тут, но давайте вспомним основные моменты:

▫️Классифицируем - не весь долг одинаково вреден. Мы сделали это намеренно, чтобы успеть, или это просто получилось из-за спешки/неопытности? Мы понимали риски, или просто делали на шару?
▫️Обозначаем - создаем задачи на погашение, маркируем их специальным тегом (tech-debt) и складываем в бэклог. Это делает проблему видимой для всей команды и менеджмента
▫️Приоритизируем - Какой долг самый дорогой? Тот, который замедляет разработку самых важных бизнес-фич. То есть оптимизируем то, что команда трогает каждый день. И обязательно под это выделяем фиксированный процент времени в каждом спринте (например, 15-20%)

Это не про написание идеального кода, а про экономику разработки

2️⃣Легаси

Перед нами старый монолит. Он работает, приносит деньги, но каждая новая фича в нем — это боль и страдания. Каждый месяц приходят ребята с предложениями все переписать с нуля. И это очень опасная ловушка, потому что вероятность доведения до конца не 100%

Если погуглить, мы найдем понятие "эволюционная модернизация". И сразу один из самых мощных паттернов для этого - Strangler Fig Pattern.

Что делаем:

▫️Ставим прокси, чтобы ходить в старую систему через него. Изначально он просто проксирует все запросы в старую систему (фасад)
▫️Новую функциональность (или переписываемый кусок старой) мы реализуем в виде отдельного, нового сервиса
▫️В конфигурации фасада мы меняем одно правило: запросы, относящиеся к новой функциональности, теперь идут на новый сервис, а все остальные по-прежнему на старый.

И так шаг за шагом мы освобождаем от монолита функциональность, реализуя ее в новых сервисах и переключая роутинг. Со временем старая система перестанет получать трафик и ее можно безболезненно отключить. Этим подходом мы модернизируем легаси итеративно с постоянной поставкой ценности для бизнеса.

3️⃣Связность и зацепление

В нашей зоне ответственности вся архитектура. И здесь иногда возникают моменты с гибкостью: высокое зацепление (Coupling) и низкая связность (Cohesion).

🌟Зацепление (Coupling): Насколько сильно два компонента (модуля, сервиса) зависят друг от друга. Если изменение в сервисе А постоянно требует изменений в сервисе Б - у нас высокий Coupling
🌟Связность (Cohesion): Насколько хорошо код внутри одной компоненты связан общей задачей. Если один микросервис отвечает и за профили пользователей, и за расчет доставки - у него низкий Cohesion

Что делать:

▫️Анализируем, какие сервисы чаще всего меняются вместе. И даже когда один сервис ходит в базу данных другого
▫️Определяем границы. Например, сервис "Заказы" не должен знать, как работает "Склад", их общение должно идти через четкие, публичные API.
▫️Визуализируем - строим карту зависимостей между нашими сервисами. Иногда просто по схеме можно найти архитектурные проблемы

Все понятно

По сути работа с сервисом - это не сделал один раз и запустил. Это марафон, состоящий из небольших, регулярных стратегических действий. Будет это тяжелый и потный марафон, либо более приятный - зависит и от нас, и от внешних условий. Но с этими инструментами мы по крайней мере будем к этому готовы.

@teamleadosh

#career