На бумаге — простое правило: модуль импортирует только то, что ему положено.
На практике — его иногда нарушают. И последствия оказываются внезапными и дорогими.
Пару раз в жизни я меняла локальный метод в сервисе, будучи уверена, что трогаю только свой модуль. Но в проде падала функциональность в совершенно другой части продукта. 😅
Причина оказалась одна: неочевидный прямой импорт, который связал, казалось бы, независимые куски архитектуры.
Вывод: правило «не импортировать всё подряд» — не архитектурная прихоть. Это практический способ держать систему предсказуемой, управляемой и масштабируемой.
Эта пара реальных инцидентов объясняет, почему правило «не импортировать всё подряд» — не абстрактная архитектурная прихоть, а практический способ удерживать систему предсказуемой, управляемой и масштабируемой.
Почему свободные импорты опасны
⏺️ Скрытые зависимости. Усложняют оценку влияния правки — локальная правка может иметь глобальные последствия;
⏺️ Рост затрат на тестирование. Чтобы воспроизвести баг, нужно поднимать большие части системы;
⏺️ Размытое ownership. Никто не уверен, кто отвечает за изменение — баги «прыгают» между командами;
⏺️ Страх рефакторить. Любое изменение становится рискованным и медленным.
В больших системах главное — сохранять локальность изменений. Если небольшая правка начинает ломать удалённые части продукта, это почти всегда сигнал о проблемах в границах модулей. Контроль импортов — один из самых простых и эффективных способов вернуть системе предсказуемость и сделать развитие продукта управляемым. 👍