На ревью предлагают вынести общий код в библиотеку, чтобы два модуля не дублировали его. Как понять, что библиотека станет скрытой общей границей?
Библиотека становится скрытой общей границей, если её изменения требуют синхронной координации модулей или заставляют их принимать одинаковую модель и темп эволюции. Безопасно делить код стоит тогда, когда его смысл, правила изменения и ответственность действительно общие; иначе небольшое дублирование часто дешевле связанности.
Повторное использование библиотек появилось как способ уменьшить стоимость разработки и устранить расхождения в одинаковой логике. Однако модульность преследует другую цель: локализовать изменения и позволить частям системы развиваться независимо.
Поэтому общий код создаёт не только экономию, но и обязательство совместно поддерживать его контракт. В архитектуре это компромисс между устранением дублирования и сохранением независимых границ.
Два модуля могут использовать одинаковую реализацию сегодня, но иметь разные причины для будущих изменений. Если такую реализацию сразу вынести в общую библиотеку, изменение требования одного модуля может потребовать выпуска библиотеки и проверки второго.
Риск особенно велик, когда библиотека содержит не техническую утилиту, а бизнес-правила, модели или значения, смысл которых различается в разных контекстах. Тогда формально общий код скрывает семантическую связанность и постепенно превращается в точку координации релизов.
Главный критерий — совместная причина изменения. Нужно проверить, меняется ли код по одним и тем же бизнес-правилам, принадлежит ли одной ответственности и допустимо ли для обоих модулей одинаковое направление эволюции.
Также оценивают стоимость контракта библиотеки:
Если библиотека содержит стабильную техническую абстракцию с узким контрактом, например общий механизм сериализации или измерения времени, совместное использование обычно оправдано. Если она содержит предметные правила, общий объект или удобный набор функций, который постепенно начинает учитывать исключения каждого потребителя, граница становится опасной.
Возможны три решения. Общая библиотека уменьшает дублирование, но связывает выпуск и дизайн потребителей. Раздельные реализации допускают контролируемое дублирование, зато сохраняют автономию и позволяют адаптировать правила. Общий контракт с отдельными адаптерами оставляет согласованным внешний смысл, но не заставляет модули делить внутреннюю модель.
Практическое правило: сначала разделяют устойчивую абстракцию, а не текущий фрагмент одинакового кода. Если независимость важнее устранения нескольких строк дублирования, дублирование является осознанной платой за слабую связанность.
В системе расчёта доставки и в системе возвратов обнаружили одинаковую функцию определения доступности региона. Команда предложила общую библиотеку, но анализ показал, что доставка учитывает зоны перевозчиков, а возвраты — ограничения пунктов приёма; правила меняются разными подразделениями.
Рассматривались варианты. Общая библиотека устраняла дублирование, но требовала совместного согласования каждого изменения. Полное дублирование сохраняло независимость, однако могло привести к расхождению действительно общих технических правил. Единая предметная модель выглядела аккуратно, но смешивала разные смыслы региона.
Выбрали отдельные предметные реализации и маленькую общую техническую библиотеку для нормализации входных данных. Это решение сохранило независимые границы, а различия бизнес-правил стали явными. Результатом стала возможность выпускать изменения доставки без обязательной проверки логики возвратов.
Нет. Дублирование реализации и дублирование знаний — разные вещи. Если два участка должны изменяться одинаково по одному правилу, расхождение опасно и общий компонент может быть полезен. Если одинаковыми являются только текущие строки кода, объединение создаёт связанность без гарантии долгосрочной пользы.
Версии позволяют технически выпускать изменения поэтапно, но не отменяют необходимость согласовать смысл контракта. Если потребители обязаны перейти на новую модель или совместно интерпретировать изменённое правило, координация остаётся, даже когда старые версии временно поддерживаются.
Нужно проверить историю и направление изменений: кто владеет правилом, какие требования его меняют и возникают ли у потребителей разные исключения. Стабильная абстракция имеет узкий смысл и не требует постоянного добавления условий для отдельных модулей. Если библиотека начинает принимать параметры и расширения ради несовместимых сценариев, это сигнал вернуть предметную логику за границы модулей.