Модуляризация монолита без остановки разработки
Вопрос
У вас монолитное приложение на 300 тысяч строк и 5 команд. Как модуляризировать, не останавливая фичи?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Измерить: время сборки, граф зависимостей, частота изменений
Сначала инфраструктура (core), потом фичи с наибольшей выгодой
Strangler: новые фичи сразу модулями, старые постепенно
Правила и автоматические проверки графа
Метрики результата: время инкрементальной сборки, конфликты
Договорённости с командами и владение
Что могут спросить следом
- Как вы обоснуете затраты бизнесу?
- Что делать с общими моделями, которые нужны всем?
Разбор
Начинаю с измерений: время чистой и инкрементальной сборки, граф зависимостей и какие части меняются чаще всего. Это и аргумент для бизнеса: сколько часов в неделю команды ждут сборку. Затем вытаскиваю инфраструктуру в core-модули: сеть, хранилище, дизайн-систему, иначе любая фича потянет за собой монолит. Новые фичи сразу пишем модулями, а старые переносим по одной, начиная с тех, что меняются чаще и сильнее всего тормозят сборку. Это strangler-подход: монолит постепенно худеет, разработка не останавливается. Вводим правила зависимостей и проверку графа на CI, владельцев модулей через CODEOWNERS. Каждые пару недель смотрю метрики: время инкрементальной сборки и число конфликтов при слиянии.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Ещё по теме «Модульность»
- Почему сборка не ускорилась после модуляризации
- Что выносят в core-модули
- Циклические зависимости модулей
- Зависимость фичи от фичи
- Инструменты модуляризации на Android
- Инструменты модуляризации на iOS
- Типы модулей мобильного приложения
- api и implementation в Gradle