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

Ощущение «своего» кода и личная вовлечённость

В большом монолите легко потерять ощущение причастности: ты меняешь какую‑то строчку в огромном файле, который правили ещё до твоего прихода, и не чувствуешь, что это «твой» результат.

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

И это не про «гордыню», а про ответственность: если ты сам принимаешь решения в своём модуле, ты и будешь первым, кто столкнётся с последствиями, если что‑то пойдёт не так. Об этом же я уже упоминал, когда писал про вред Core-команд (тут и тут).

Локализация ошибок и снижение страха перед изменениями

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

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

Такой подход сильно снижает когнитивную нагрузку: не нужно держать в голове всю систему, чтобы сделать небольшое улучшение. Достаточно понимать свой модуль и его интерфейсы.

Независимые релизы и гибкость поставки

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

Благодаря модуляризации мы смогли приблизить этот сценарий: отдельные модули могут иметь свои релизные циклы и даже свои версии. Да, в итоге всё собирается в единый билд, но команды могут двигаться с разной скоростью, не блокируя друг друга.

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

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

В следующем посте поговорим о еще одном, самом важном плюсе модуляризации: возможность нивелировать негативное влияние эффекта Рингельмана и законов Брукса и Миллера и сокращать ненужную работу.

Не переключайтесь! 🔥