Приведи пример, когда высокая связность элементов мешала

Пример высокой связности, мешающей развитию проекта

Позвольте привести реалистичный пример из моего опыта работы над крупным SPA-приложением для электронной коммерции. Мы столкнулись с серьёзными проблемами из-за высокой связности (tight coupling) между компонентами, которая мешала как развитию функциональности, так и поддержке кода.

Контекст проблемы

Изначально архитектура приложения развивалась органически: был создан монолитный модуль OrderManager, который отвечал за весь жизненный цикл заказа — от корзины до оплаты и истории. Со временем он превратился в "божественный объект" (God Object), тесно связанный с множеством других частей системы.

// Пример фрагмента проблемного кода (упрощённо)
class OrderManager {
  constructor() {
    this.cart = new CartService();
    this.payment = new PaymentService();
    this.inventory = new InventoryService();
    this.notification = new NotificationService();
    this.analytics = new AnalyticsService();
  }
  
  async processOrder(userId, items) {
    // 1. Проверка наличия товаров
    const inventoryCheck = await this.inventory.checkAvailability(items);
    
    // 2. Обновление корзины
    await this.cart.update(userId, items);
    
    // 3. Расчёт доставки (жёсткая привязка к конкретному сервису)
    const shipping = await ShippingCalculator.calculate(items);
    
    // 4. Создание платёжного интента
    const paymentIntent = await this.payment.createIntent({
      userId,
      amount: this.cart.total + shipping,
      items
    });
    
    // 5. Отправка уведомлений
    await this.notification.sendOrderCreated(userId);
    
    // 6. Отправка аналитики
    await this.analytics.track('order_processed', { userId });
    
    // 7. Обновление инвентаря
    await this.inventory.reserveItems(items);
    
    // ... и ещё 10+ операций
  }
}

Как высокая связность мешала проекту

1. Невозможность независимого тестирования

• Чтобы протестировать логику оплаты, приходилось создавать полное окружение: мокать инвентарь, корзину, уведомления.
• Unit-тесты превращались в интеграционные, их выполнение занимало минуты вместо секунд.

2. Эффект домино при изменениях Когда потребовалось добавить новую логику расчёта скидок:

// Пришлось модифицировать КАЖДЫЙ метод, связанный с заказом
async processOrder(userId, items) {
  // Добавили новую зависимость
  const discounts = await new DiscountService().calculate(userId, items);
  // Изменили расчёт суммы
  const amount = this.cart.total + shipping - discounts.total;
  // Обновили аналитику
  await this.analytics.track('discount_applied', { userId, discounts });
  // ... и ещё в 8 местах
}

Одно изменение потребовало правок в 12 файлах и привело к трём регрессионным багам.

3. Блокировка параллельной разработки

• Два разработчика не могли одновременно работать над улучшением корзины и оплаты — их изменения постоянно конфликтовали в OrderManager.
• Фронтенд-разработчики ждали бэкенд, когда те переделывали API инвентаря, потому что модули были неразделимы.

4. Нереализуемость новых требований Бизнес запросил возможность оформления заказа без регистрации (гостевой режим). Это потребовало:

• Обхода системы уведомлений (нет email)
• Изменения аналитики (другой тип пользователя)
• Особой логики корзины (временная vs постоянная)

Вместо изящного решения пришлось добавлять бесконечные условия:

async processOrder(userId, items, isGuest = false) {
  if (!isGuest) {
    await this.notification.sendOrderCreated(userId);
  } else {
    await this.guestNotification.sendTempNotification(email);
  }
  
  if (this.payment.isAvailableForGuest(isGuest)) {
    // ... ветвление продолжается
  }
}

5. Катастрофическое увеличение сложности За два года метод processOrder вырос до 400 строк, принимал 8 параметров и имел 12 внешних зависимостей. Его цикломатическая сложность превысила 50, что делало код практически неподдерживаемым.

Последствия и решение

Последствия высокой связности:

• Скорость разработки упала на 60% за год
• Количество багов в регрессии увеличилось втрое
• Onboarding новых разработчиков занимал 3 месяца вместо 3 недель
• Деплой стал рискованным — даже мелкие изменения требовали полного прогона всех тестов (2+ часа)

Принятое решение — рефакторинг через внедрение принципов SOLID:

1. Разделение ответственности — создали отдельные модули: CartModule, PaymentModule, InventoryModule
2. Внедрение Dependency Injection — заменили жёсткие связи на абстракции
3. Шаблон "Медиатор" — для координации сложных процессов оформления заказа
4. Event-Driven архитектура — переход на слабосвязанную коммуникацию через события

// После рефакторинга
class OrderProcessingService {
  constructor(eventBus) {
    this.eventBus = eventBus; // Единственная зависимость
  }
  
  async startOrderProcess(orderData) {
    await this.eventBus.publish('ORDER_INITIATED', orderData);
    // Дальше работают независимые обработчики
  }
}

// Модули стали независимыми
class PaymentHandler {
  async handleOrderInitiated(event) {
    // Знает только о платежах
    const intent = await this.createPaymentIntent(event.data);
    await this.eventBus.publish('PAYMENT_CREATED', intent);
  }
}

Выводы

Этот опыт наглядно показал, что высокая связность — это не просто теоретический антипаттерн, а практическая проблема, которая:

• Экспоненциально увеличивает стоимость изменений
• Создает скрытые точки отказа
• Превращает agile-разработку в waterfall из-за необходимости синхронизировать все изменения
• Делает систему хрупкой — падение одного сервиса может привести к коллапсу всей функциональности

Ключевой урок: инвестиции в слабую связность (loose coupling) и высокую связность модулей (high cohesion внутри модулей) окупаются уже на среднесрочной перспективе, даже если изначально требуют больше времени на проектирование. Современные подходы — микросервисы на бэкенде, микрофронтенды и модульная архитектура на фронтенде — прямое следствие борьбы с проблемами, которые вызывает излишняя связанность компонентов.