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

Устраивайтесь поудобнее: будет история про провальную попытку внедрения модуляризации.

Дисклеймер: все совпадения случайны. Автор описывает вымышленную команду из вселенной Незнайки на Луне.

Разберём кейс по знакомому STAR‑фреймворку.

Situation (Ситуация)

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

Task (Задача)

Сохранить: * управляемость командой; * контроль над кодовой базой; * эффективность производства — несмотря на скорое увеличение штата.

Action (Действия)

Команда приняла решение внедрить модуляризацию. При этом сразу выбрали амбициозный подход — разнести пакеты и модули по мультирепозиториям (multi‑repo), минуя этап работы с единым монорепозиторием.

Result (Результат)

Результат получился далёк от ожиданий. Команда Незнайки выразила серьёзное недовольство проведённой модуляризацией. Разработчики настойчиво просят: * вернуть монорепозиторий; * возможно, даже отменить разбивку на пакеты. Почему так вышло? На первый взгляд, решение казалось идеальным, но на практике столкнулись с серьёзными проблемами: 1. Нечеткое определение границ модулей. 2. Избыточная гранулярность. 3. Необходимость перестройки процессов. 4. Синхронизация версий. 5. Обучение команды. 6. Сопротивление изменениям. 7. Временное снижение продуктивности.

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