Коннасенс

Коннасенс — это связанность с точным определением: два компонента коннасны, если изменение одного требует изменить другой, чтобы остаться корректным. Вот и всё — но точность важна. Она даёт бинарный тест для любых двух кусков кода: если я меняю A, обязан ли я также менять B, чтобы программа осталась корректной? Если да — они коннасны, и теперь можно задать единственные два вопроса, которые имеют значение: насколько сильный коннасенс и насколько далеко друг от друга живут эти два куска.

// Эти две строки коннасны: вызывающий и функция
// договорились, что ВТОРОЙ аргумент — это таймаут. Поменяй порядок
// в createConn — и этот вызов молча неверен, но всё ещё компилируется.
function createConn(host: string, timeoutMs: number) { /* ... */ }
createConn("db.internal", 5000);

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

Статический коннасенс — видимый при чтении кода — приходит в порядке силы, который можно запомнить. От слабейшего к сильнейшему: имя (два места должны согласовать имя, например функция и её вызывающий разделяют taxFor), тип (должны согласовать тип), смысл/соглашение (должны согласовать, что 0 означает «гость», а 1 — «админ» — магическое значение), позиция (должны согласовать порядок вещей, например позиционные аргументы) и алгоритм (должны согласовать общее вычисление, например обе стороны должны хешировать пароль одинаково).

// Коннасенс смысла: каждое место должно «знать», что 1 = админ.
if (user.role === 1) showAdminPanel();   // 1 означает... что?
// Коннасенс имени (слабее): договорённость — это общее имя.
if (user.role === Role.Admin) showAdminPanel();

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

Динамический коннасенс — видимый только в рантайме — строго хуже, потому что договорённость невидима в исходнике. Формы: порядок выполнения (B должно выполниться после A, например open() до read()), тайминг (гонка — корректность зависит от когда, а не только от порядка), значение (несколько значений должны меняться вместе, чтобы остаться согласованными, например инвариант min/max или скидка, которая должна совпадать с итогом) и идентичность (две ссылки должны указывать на один и тот же экземпляр объекта, а не просто на равные).

// Коннасенс порядка выполнения: вызывающие обязаны вызывать это
// по порядку, и ничто в типах об этом не говорит. Переставь их —
// и оно компилируется, выполняется и портит состояние.
txn.begin();
txn.write(row);
txn.commit();   // должно быть последним — но кто это обеспечит?

Статический коннасенс можно найти, поискав по коду; динамический находишь, отлаживая прод. Вот почему зависимость от порядка или инвариант общего изменяемого значения — более громкий запах, чем позиционный аргумент: то же семейство, хуже локальность боли.

Два правила превращают таксономию в компас: предпочитай более слабый коннасенс и предпочитай более локальный коннасенс. Сила говорит, какой вид дороже сопровождать; локальность говорит, что тот же вид намного дешевле, когда оба конца сидят рядом. Коннасенс позиции между двумя аргументами одной приватной функции тривиален — оба конца на одной строке, которую ты контролируешь. Тот же коннасенс позиции в публичном API, который потребляют двенадцать команд, — это проект миграции. Локальность часто рычаг побольше: обычно нормально иметь сильный коннасенс внутри маленького связного модуля (это и есть связность) и катастрофа — иметь даже слабый коннасенс, пересекающий границы модулей или сервисов.

Поэтому senior-ход, когда ты замечаешь связанность, — это два вопроса по порядку: могу ли я сделать её слабее (сдвинуться вниз по лестнице силы), а если нет — могу ли я сделать её локальнее (стянуть оба конца в один модуль). Любой из этих ходов — реальное, защитимое улучшение, и теперь ты можешь точно сказать, какой именно сделал.