Модуль 1 · Урок 3 · ~10 минут

Связи между частями системы

Одна идея этого урока: опасна не сложность частей, а сложность связей – меняешь одно, дёргается всё.

Знакомая ситуация

Ты просишь агента поменять формат записи ученика: добавить к имени телефон. Агент меняет – и через день выясняется: бот записывает по-новому, планировщик рассылок читает по-старому и молча теряет людей, а отчёт в личном кабинете показывает кашу. Ни одна из частей не сломана – сломалась договорённость между ними.

Часы отладки уходят не на сами модули, а на невидимые нити между ними. Этот урок – про то, как эти нити замечать и укорачивать.

Хрупкость системы измеряется не размером частей, а количеством и скрытностью связей между ними. Чем больше частей должны «знать» об одном изменении, тем дороже каждое изменение.

Два слова, одно правило

У инженеров есть пара терминов для разговора о связях:

1
Связанность couplingНасколько сильно части системы зависят друг от друга: если поменять одну – придётся ли трогать другую? Это про нити МЕЖДУ модулями. Чем их меньше и тоньше, тем лучше.
2
Связность cohesionНасколько содержимое одного модуля относится к одному делу: всё про оплату – в «оплате», всё про расписание – в «расписании». Это про сцепление ВНУТРИ модуля. Чем выше, тем лучше.

Классическое правило «high cohesion, low coupling» простым языком: родственное – держи вместе, чужое – связывай минимально. Это продолжение урока 2: у глубокого модуля связность высокая (всё знание об оплате в одном месте), а связанность низкая (наружу торчит одна простая кнопка).

Скрытые связи – самые дорогие

Явная связь видна: модуль А вызывает модуль Б. Настоящие проблемы создают связи, которых не видно ни тебе, ни агенту в новой сессии:

1
Общие данные shared global stateНесколько частей читают и пишут одну «общую тетрадь»: таблицу, файл настроек, глобальную переменную. Любой может испортить данные любому – и виновника не найти.
2
Дублированная логика duplicated logicОдно правило (расчёт скидки, проверка доступа) скопировано в несколько мест. Копии обязаны меняться вместе, но напоминания об этом нет – однажды обновят одну и забудут вторую.
3
Неявные договорённости implicit contractsЧасти полагаются на формат, порядок или тайминг, которые нигде не зафиксированы: «дата всегда в таком виде», «это поле всегда заполнено». В одном месте формат поменял – в трёх сломалось, как в истории выше.

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

Как думают три уровня

ДжунСвязей не видит вообще – узнаёт о них от багов. Меняет то, что просили, и искренне удивляется, что сломалось в другом месте. Копирует логику не задумываясь: «так быстрее». Агент без надзора ведёт себя так же.
МидлЯвные связи видит и проверяет: «этот модуль вызывается вот здесь и здесь». Но скрытые – общие данные, копии логики, негласные форматы – пропускает, потому что в коде они не выглядят как связи.
СеньорПроектирует так, чтобы связей было мало и все были явными: одно правило – одно место, общие форматы зафиксированы, а не подразумеваются. Перед любой правкой задаёт вопрос: «кто ещё об этом знает?» – и требует список, а не догадки.

Проверь себя

1. Ты попросил поменять формат даты в отчётах бота. Сломались лендинг и планировщик, которые ты не трогал. Главный вывод сеньора?

2. Что из перечисленного – признак хорошей структуры?

3. Агент предлагает: «Чтобы бот и лендинг не зависели друг от друга, продублирую расчёт цены в обоих». Твой ответ как сеньора?

Что говорить агенту уже сегодня

Источники