Миграция архитектуры приложения для маленькой команды: не ждите идеального плана

Миграция архитектуры приложения для маленькой команды: не ждите идеального плана

Несколько лет назад, когда я ещё работал с Flutter и адаптацией под HarmonyOS, коллега спросил меня: «Наша текущая архитектура работает нормально, зачем её менять?» Я тогда не смог ответить, потому что она действительно работала. Но через три месяца новая функция заняла вдвое больше ожидаемого времени именно из-за того, что архитектура плохо адаптировалась к изменениям бизнеса.

Для маленькой команды самая сложная часть миграции архитектуры — не техническая задача, а решение. Вы ищете в интернете и находите бесконечные статьи о микросервисах, модульности, Clean Architecture. Но эти грандиозные нарративы часто становятся обузой для команды из трёх-пяти человек.

Когда стоит мигрировать?

Я выработал простое правило: Если добавление или изменение функции последовательно занимает более чем вдвое больше ожидаемого времени, и это происходит три или более раз подряд, пора серьёзно рассмотреть корректировку архитектуры.

Это не догадка. Посмотрите на свои задачи за последние две недели. Если три разные функции были отложены из-за «сцепления кода», «беспорядка зависимостей» или «отсутствия тестового покрытия», архитектура — узкое место, а не люди.

Пять принципов миграции архитектуры для маленькой команды

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

1. Не мигрируйте всё сразу.

Крупные компании могут потратить полгода на переписывание всего приложения. Маленькие команды не могут. Как только вы остановите разработку функций, денежный поток станет напряжённым, и начальник (часто вы сами) начнёт нервничать. Мой подход: сначала определите самый болезненный модуль. Возможно, модуль входа/регистрации связан со слишком большой бизнес-логикой, или модуль оплаты требует изменения в пяти местах при каждом изменении. Мигрируйте только этот модуль; остальное оставьте как есть.

2. Новая архитектура должна приносить немедленную выгоду.

Если через две недели вы не увидите явного улучшения скорости разработки или уменьшения количества ошибок, возможно, ваше направление неверно. Немедленная выгода может быть: время разработки новой функции сократилось на 30%, или часто падающая страница перестала падать. Не говорите себе «это окупится в долгосрочной перспективе» — для маленькой команды существует только следующий релиз.

3. Используйте инверсию зависимостей вместо полной развязки.

У маленьких команд нет ресурсов для идеального внедрения зависимостей и проектирования интерфейсов. Вам нужно сделать только одно: сделать так, чтобы бизнес-логика не зависела напрямую от конкретных фреймворков или сторонних библиотек. Например, оберните сетевые запросы в абстрактный слой, чтобы смена сетевой библиотеки затрагивала только этот слой. Для других частей используйте повторно, где возможно; не гонитесь за чистотой.

4. Тестовое покрытие — не обязательное условие, а побочный продукт миграции.

Многие статьи говорят «сначала напишите тесты, потом рефакторите», но у маленьких команд часто нет тестов. Мой опыт: во время миграции, когда вы изменяете старый модуль, добавьте несколько ключевых тестов. Не нужно полного покрытия — просто покройте наиболее распространённые пользовательские сценарии. К моменту завершения миграции у вас уже будут некоторые тесты.

5. Сохраняйте механизм отката.

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

Конкретный ритм миграции

Предположим, вы решили действовать. Каков ритм? Я рекомендую «трёхнедельный ритм»:

• Первая неделя: Диагностика и проектирование. Потратьте три дня на построение графа зависимостей самого болезненного модуля (подойдёт бумага и ручка или доска). Затем потратьте два дня на проектирование интерфейсов нового модуля — сосредоточьтесь только на том, как этот модуль становится независимым, не думайте глобально.
• Вторая неделя: Реализация и тестирование. Используйте одну неделю для реализации нового модуля в отдельной ветке, написав несколько ключевых тестов. Не сливайте в основную ветку на этом этапе.
• Третья неделя: Переключение и мониторинг. Разверните новый модуль за Feature Flag и начните мониторинг ключевых метрик (частота сбоев, время запуска, использование функций). Если всё стабильно, удалите старый код через неделю.

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

Гипотетический пример

Представьте, что у вас есть приложение для электронной коммерции, где модуль заказа — от оформления заказа до оплаты и доставки — весь написан в одном Activity или странице. Каждый раз, когда вы изменяете логику оплаты, вы рискуете сломать логику доставки. Это явно требует разделения.

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

Ошибки, которые вы можете совершить

• Избыточное проектирование интерфейсов. Для маленькой команды количество интерфейсов должно быть однозначным. Если новый модуль раскрывает дюжину интерфейсов, вы либо неправильно разделяете, либо пытаетесь решить все будущие проблемы сразу.
• Игнорирование знакомства команды. Вы выбираете модный архитектурный паттерн, но никто в команде его не использовал. Миграция превращается в учебный проект, удваивая время разработки. Отдавайте приоритет тому, что команда уже знает, даже если это менее «продвинуто».
• Отсутствие коммуникации с заинтересованными сторонами. Если вы технический лидер, заранее сообщите продакт-менеджеру или начальнику: в ближайшие три недели новые функции для этого модуля могут быть медленнее, но потом они станут быстрее. Иначе они усомнятся в вашей эффективности уже на второй неделе.

Резюме

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

Если вы колеблетесь, спросите себя: сколько раз за последние две недели архитектура стала причиной задержек? Если ответ — три или более, пора действовать.

PaxLee