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

Нечёткие границы модулей — корень всех бед

Главная проблема, с которой столкнулась команда Незнайки, — неудачно выделенные границы. А ведь именно в этом и есть суть модуляризации: не просто нарезать код на куски, а добиться Low Coupling/High Cohesion. То есть внутри модуля всё тесно связано по смыслу, а между модулями — минимум связей. Если границы выбраны искусственно, то связанность (coupling) остаётся высокой, а стоимость поддержки кода — такой же дорогой, как и в монолите. Более того, добавляются ещё и инфраструктурные расходы: новые репозитории, пайплайны, артефакты. В итоге вы платите больше, а выигрыша не получаете.

Избыточная гранулярность: когда «слишком мелко» — это плохо

Ещё одна частая ошибка — делать модули слишком мелкими. Это увеличивает накладные расходы на их взаимодействие и поддержку. Здесь выручает принцип Single Responsibility: у модуля должна быть одна причина для изменения, и одно изменение должно затрагивать один модуль.

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

У нас подход был другим: продуктовые пакеты менялись только под продуктовые задачи, и обычно — без затрагивания других пакетов. Системные пакеты (например, компоненты дизайн‑системы) обновлялись по отдельным задачам и не тянули за собой продуктовые.

Перестройка процессов: DevOps — не опция, а необходимость

Переход на модуляризацию — это не только про код. Приходится менять пайплайны сборки, релизные циклы, тестирование. И поддерживать это нужно уже не в одном репозитории, а в каждом пакете — а их становится много.

Масштабировать такие процессы вручную невозможно: нужна шаблонизация и DevOps‑практики. В нашем случае iOS‑разработчикам пришлось самим осваивать эти практики, потому что DevOps‑отдел не покрывал iOS‑инфраструктуру.

Вывод: нечёткие границы и избыточная гранулярность — это не «нюансы», а критические ошибки. Если их не учесть, модуляризация не снизит сложность, а создаст новую.

А вы сталкивались с тем, что «разрезание» монолита только увеличивало затраты? Расскажите в комментариях — мне очень интересно!

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