6.09. Цикломатическая сложность

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Разработчику Архитектору

Цикломатическая сложность

Цикломатическая сложность

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

Истоки понятия

Понятие было впервые введено Томасом Маккейбом в 1976 году в статье «A Complexity Measure», опубликованной в журнале IEEE Transactions on Software Engineering. Маккейб, работавший в то время в области верификации программного обеспечения, искал объективный способ охарактеризовать «запутанность» алгоритмов независимо от языка реализации. Его гипотеза состояла в том, что сложность программы, определяемая числом возможных последовательностей выполнения, должна быть напрямую связана с трудоёмкостью её тестирования, вероятностью наличия дефектов и устойчивостью к изменениям. За основу он взял математический аппарат теории графов — в частности, понятие циклического ранга неориентированного графа. Однако в применении к программам этот подход был адаптирован к управляющему графу потока управления (control flow graph, CFG), где узлы соответствуют базовым блокам кода (последовательностям операторов без ветвлений), а направленные рёбра — возможным переходам между ними.

Важно понимать: цикломатическая сложность — это топологическая, а не семантическая характеристика. Она не учитывает смысл условий, глубину вложенности или объём данных, но отражает структурную организацию логики принятия решений. Два фрагмента кода с абсолютно разными доменными задачами могут иметь идентичную цикломатическую сложность, если их графы потока управления топологически эквивалентны. Эта «слепота к содержанию» — одновременно и ограничение, и сила метрики: она позволяет сравнивать модули в разных языках и предметных областях, выявляя общие паттерны структурной перегрузки.

Что именно измеряется

Суть цикломатической сложности заключается в подсчёте линейно независимых путей через программный модуль. Путь здесь понимается как последовательность базовых блоков от точки входа к точке выхода, а независимость — в том смысле, что хотя бы один блок или переход в этом пути не встречался в предыдущих учтённых путях. Например, в простейшей функции без ветвлений существует ровно один путь — последовательное выполнение всех операторов. Добавление одного оператора if без else увеличивает количество независимых путей до двух: путь, проходящий через тело условия, и путь, его обходящий. Каждое дополнительное условие, не находящееся в строгой линейной зависимости от предыдущих, — будь то вложенное ветвление, цикл с предусловием или логическое И/ИЛИ — добавляет новые ветви в граф потока управления и, как следствие, увеличивает общее число независимых маршрутов.

Отсюда вытекает ключевой практический вывод: значение цикломатической сложности определяет минимальное количество тестовых сценариев, необходимых для обеспечения покрытия всех возможных логических путей в функции. Это не означает, что столько же тестов достаточно — например, из-за взаимодействия переменных могут потребоваться дополнительные комбинации входных данных, — но оно задаёт нижнюю границу трудозатрат на полное ветвевое покрытие (branch coverage). Таким образом, метрика служит не просто индикатором структурной запутанности, но и инструментом планирования тестирования.

Связь с другими аспектами качества кода

Цикломатическая сложность редко рассматривается изолированно. Её значение приобретает смысл в контексте других характеристик модуля:

• Читаемость и восприимчивость — рост числа независимых путей прямо коррелирует с когнитивной нагрузкой на разработчика. При чтении кода человек мысленно проигрывает возможные сценарии его выполнения. Если таких сценариев десятки, даже при хорошей документации и именовании вероятность упустить крайний случай резко возрастает.

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

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

• Надёжность — эмпирические исследования, включая работы самого Маккейба, показывают положительную корреляцию между цикломатической сложностью и частотой возникновения дефектов. Это объясняется трудностью тестирования и большей вероятностью логических ошибок в процессе написания: чем больше ветвлений, тем выше шанс, что разработчик неверно оценит взаимодействие условий или упустит граничный случай.

Высокая сложность сама по себе не порождает ошибки, но создаёт среду, в которой они легче возникают и дольше остаются незамеченными.

Практические пороги и интерпретация значений

Хотя цикломатическая сложность формально не ограничена сверху, в инженерной практике сложились устойчивые ориентиры, основанные на многолетнем опыте команд и стандартах качества:

• 1–5 — тривиальная логика. Как правило, последовательные операторы, возможно, с одним простым условием. Такие модули легко читаются, тестируются и сопровождаются. Риск ошибок минимален.

• 6–10 — умеренная сложность. Разумный верхний предел для большинства повседневных функций. Требует внимательного именования, документирования условий и хотя бы базового покрытия тестами.

• 11–20 — высокая сложность. Функция, достигшая этого порога, заслуживает критического пересмотра. Здесь уже трудно удержать в голове все возможные пути, а написание полного набора тестов становится нетривиальной задачей. Часто такие модули содержат несколько взаимосвязанных логических задач, объединённых в одном месте по историческим или архитектурным причинам.

• 21 и выше — критическая сложность. Такие модули считаются неприемлемыми в зрелых кодовых базах. Их присутствие сигнализирует либо о глубоких проблемах в проектировании (например, нарушении принципа единственной ответственности), либо о длительном техническом долге без рефакторинга. Вероятность наличия скрытых дефектов многократно возрастает; внесение изменений без регрессии практически невозможно без предварительного разбиения.

Некоторые стандарты, такие как MISRA C или CERT C, прямо запрещают превышение порога 10 для отдельных функций в критически важных системах (авионика, медицинское оборудование, АСУ ТП). В коммерческой разработке, где баланс между скоростью и надёжностью более гибок, допускаются и бо́льшие значения, но только при наличии веских оснований и компенсирующих мер — например, автоматизированных тестов с покрытием >95 % по ветвям.

Как сложность проявляется в реальном коде

Рассмотрим, какие конструкции и практики наиболее активно увеличивают цикломатическую сложность.

Во-первых, это последовательные условные операторы, особенно если они не связаны логически. Серия из пяти независимых if без else if добавляет ровно пять путей (по одному на каждое условие плюс путь, где ни одно не сработало). Если же условия вложены, рост становится мультипликативным: три вложенных двоичных ветвления дают уже восемь независимых путей.

Во-вторых, логические операции в условиях. Хотя синтаксически if (A && B) выглядит как одно ветвление, с точки зрения потока управления короткозамкнутое И (&&) и короткозамкнутое ИЛИ (||) порождают дополнительные точки принятия решений: при A = false в A && B выражение B не вычисляется, что соответствует отдельному переходу в графе. Аналогично, A || B при A = true пропускает B. Поэтому сложные условия с несколькими операторами И/ИЛИ значительно увеличивают количество независимых путей, даже если внешне структура кода кажется компактной.

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

В-четвёртых, операторы множественного выбора, такие как switch/case (в языках, где отсутствие break не ведёт к обязательному проваливанию) или эквивалентные конструкции на основе хэш-таблиц или полиморфизма. Каждая ветвь case, не объединённая с другими, добавляет новый путь. Особенно опасны конструкции, где case содержат вложенные условия — в этом случае сложность складывается.

Особое место занимают исключения. В языках с механизмом исключений (Java, C#, Python) каждая конструкция try…catch потенциально добавляет альтернативный путь выполнения — через обработчик исключения. Однако реализация учёта зависит от инструмента: одни анализаторы учитывают каждый catch как отдельный путь, другие — только наличие блока catch в целом. Это делает сравнение значений между разными системами статического анализа некорректным без уточнения методики.

Наконец, неявные ветвления, такие как операторы ??, ?. (null-conditional и null-coalescing в C#), тернарный оператор ?:, вызовы методов с побочными эффектами в условиях — всё это, хоть и экономит строки кода, вносит вклад в логическую сложность. Краткость синтаксиса часто вводит в заблуждение: разработчик видит «одну строчку», но фактически обрабатывает несколько сценариев выполнения.

Архитектурные и дизайновые решения как модуляторы сложности

Цикломатическая сложность измеряется на уровне отдельного модуля — как правило, функции или метода. Её значение определяется локальным стилем написания кода и глубиной архитектурных решений, заложенных на более высоких уровнях абстракции. Снижение сложности — это следствие устойчивой инженерной культуры, в которой архитектурные принципы последовательно применяются в повседневной практике.

Один из наиболее эффективных способов ограничить рост сложности — соблюдение принципа единственной ответственности (Single Responsibility Principle). Если метод реализует одну, чётко выраженную логическую операцию — например, «проверить корректность входных данных», «рассчитать итоговую сумму» или «сформировать HTTP-ответ» — он редко выходит за пределы умеренной сложности. Напротив, метод с названием processOrder() или handleRequest(), в теле которого последовательно реализована валидация, бизнес-расчёт, логирование, отправка уведомлений и запись в БД, почти неизбежно достигает критических значений. В таком случае рост сложности — симптом нарушения архитектурной дисциплины: ответственности не были выделены в отдельные компоненты, и вся логика сконденсировалась в одном месте.

Ещё один важный фактор — выбор парадигмы реализации условной логики. Традиционные императивные ветвления (if/else, switch) обладают линейной выразительной силой: каждое новое условие добавляет пути в один и тот же модуль. Альтернативные подходы позволяют «размазать» сложность по структуре системы, оставляя локальную сложность низкой:

• Полиморфизм — перенос различий в поведении в иерархию классов. Вместо гигантского switch по типу сущности метод вызывается виртуально, и конкретная реализация выбирается динамически. Цикломатическая сложность в клиентском коде падает до единицы, а логика распределяется по классам, каждый из которых отвечает за узкий контекст.

• Стратегия (Strategy) и Цепочка обязанностей (Chain of Responsibility) — паттерны, позволяющие инкапсулировать альтернативные алгоритмы или этапы обработки в отдельных объектах. Выбор конкретной стратегии или прохождение по цепочке уже не требует явного ветвления в основном потоке.

• Таблицы решений и правила в данных — вынос логики принятия решений из кода в конфигурацию (JSON, YAML, БД). Модуль становится интерпретатором, а не хранителем правил. Его сложность определяется стабильным алгоритмом применения, а не динамикой бизнес-условий.

• Событийно-ориентированная архитектура и реактивное программирование — вместо последовательной проверки состояний программа реагирует на события. Условия распределены по обработчикам; сам поток управления становится менее детерминированным, но локально каждый обработчик остаётся простым.

Все эти подходы перераспределяют общую логическую сложность системы, смещая фокус с временной организации (что делается и в каком порядке) на структурную (как организованы компоненты и их взаимодействия). Это принципиально иной тип инженерного мышления, и освоение его — ключевой этап в развитии культуры кода.

Снижение сложности

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

Настоящее снижение достигается через семантическую декомпозицию — разбиение на части, каждая из которых выражает отдельную идею, а не просто отдельный блок кода. Это требует переформулирования задачи на уровне домена. Например, вместо:

if (order.Type == "Express" && order.Weight < 5 && customer.IsVip)
    fee = 0;
else if (order.Type == "Standard" && region == "Domestic")
    fee = CalculateBaseFee(order) * 0.9;
else if (/* ... ещё 12 условий ... */)
    /* ... */

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

Такой переход невозможен без глубокого понимания предметной области и готовности инвестировать время в проектирование. Он также требует культуры, в которой время на размышление ценится не меньше, чем время на написание кода. Именно здесь цикломатическая сложность становится инструментом коммуникации: её рост — объективный аргумент в пользу пересмотра архитектуры, а не субъективное мнение разработчика о «некрасивости» кода.

Инструменты анализа

Современные среды разработки и CI/CD-конвейеры предлагают широкий спектр инструментов для измерения цикломатической сложности. В экосистеме C# это, например, SonarQube с плагином для .NET, NDepend, Visual Studio Code Metrics, ReSharper; в Java — PMD, Checkstyle, SpotBugs; в Python — radon, mccabe; в JavaScript/TypeScript — ESLint с правилом complexity, CodeClimate.

Важно различать два режима использования:

1. Интеграция в процесс разработки — проверка на этапе локальной сборки или предкоммит-хука. Здесь метрика работает как ограничитель: если сложность нового метода превышает установленный порог (например, 15), коммит блокируется или требует явного подтверждения. Это формирует привычку: разработчик учится думать о сложности в реальном времени, ещё до фиксации кода.

2. Анализ кодовой базы в целом — регулярное сканирование в CI с формированием отчётов и трендов. Здесь интерес представляет распределение: сколько методов в системе находятся в критической зоне, как меняется медиана сложности со временем, какие модули демонстрируют устойчивый рост. Такие данные позволяют выявить «горячие точки» архитектуры и приоритизировать рефакторинг на уровне релизного планирования.

Однако слепое следование цифрам опасно. Инструмент может не учитывать контекст: например, генератор парсера или компилятор выражений по своей природе обязан содержать сложные таблицы переходов — и это оправдано. Поэтому зрелая практика предполагает введение механизма исключений (suppression): каждый раз, когда допускается превышение порога, разработчик обязан оставить комментарий с обоснованием — не формально, а содержательно: «Сложность 42, потому что реализует RFC-7519 JWT-валидацию по всем разделам спецификации; все пути соответствуют различным комбинациям алгоритмов, заголовков и подписей». Такие записи становятся частью инженерной документации и помогают будущим участникам понять, где сложность — вынужденная, а где — накопленный долг.

Когнитивные пределы и эмпирические данные

Человеческий мозг имеет ограниченную способность одновременно удерживать и обрабатывать альтернативные сценарии. Исследования в области когнитивной психологии, в частности работы Джорджа Миллера («Магическое число семь плюс-минус два»), указывают на то, что объём рабочей памяти позволяет комфортно оперировать 5–9 независимыми единицами информации. В случае с цикломатической сложностью это означает: как только количество независимых путей превышает 7–9, разработчик вынужден прибегать к внешним артефактам — блок-схемам, заметкам, пошаговому трассированию — чтобы не запутаться.

Эмпирические данные подтверждают эту границу. В исследовании 2008 года, проведённом на выборке из 49 000 методов в промышленных Java-проектах, было показано, что вероятность наличия ошибок в методе резко возрастает, начиная со значения сложности 10. При 20 и выше доля методов с выявленными дефектами превышала 60 %. Похожие результаты получены в анализе C#-кода: модули со сложностью >15 в 3–4 раза чаще становились источником регрессий после изменений.

Это не означает, что значение 10 — волшебная граница, за которой «всё ломается». Но оно служит рациональной точкой пересмотра: если функция достигла этого уровня, стоит задать себе вопрос — не является ли это признаком того, что в ней смешаны несколько задач, или что в проектировании была упущена возможность абстракции.

Цикломатическая сложность как элемент культуры кода

В заключение важно подчеркнуть: метрика сама по себе нейтральна. Она не «хороша» и не «плоха» — она информативна. Её ценность определяется тем, как с ней обращаются в команде.

В незрелой культуре цикломатическая сложность становится предметом формального отчёта: «в отчёте SonarQube 23 метода с complexity > 20 — надо закрыть» — и далее следует серия механических переименований, выделений и подавлений, не затрагивающих сути. В результате отчёт «зеленеет», а читаемость и поддерживаемость не улучшаются.

В зрелой культуре — наоборот. Сложность становится поводом для диалога: на ретроспективе обсуждают, почему в этом спринте резко выросла средняя сложность в модуле оплаты; на код-ревью просят объяснить, почему в новом обработчике 17 независимых путей и нельзя ли применить стратегию; при планировании выделяют спринт-цель «снизить сложность ядра до медианы ≤8». Метрика здесь — зеркало, отражающее состояние инженерной дисциплины.

Более того, культура кода, ориентированная на управление сложностью, формирует у разработчиков особый тип профессионального чутья — способность чувствовать момент, когда логика начинает «сворачиваться в узел». Это результат многократной практики осознанного проектирования, когда каждый if задаётся не автоматически, а с вопросом: «А действительно ли это условие принадлежит сюда? Или его место — в другом слое, в другом объекте, в данных?»

Цикломатическая сложность — один из немногих объективных показателей, позволяющих перевести разговор о качестве кода из области субъективных оценок («мне кажется, тут запутанно») в плоскость инженерного рассуждения. И в этом её истинная роль в культуре кода: быть мостом между индивидуальным мастерством и коллективной ответственностью за долгосрочную жизнеспособность системы.

---

Как снижение сложности меняет реальность

Рассмотрим несколько реальных ситуаций, в которых осознанная работа с цикломатической сложностью привела к ощутимым инженерным и бизнес-результатам. Все кейсы анонимизированы, но сохраняют суть происходивших процессов.

Кейс 1. Служба расчёта тарифов в логистической платформе

В модуле расчёта стоимости доставки метод CalculatePrice имел сложность 67. Он содержал вложенную структуру из 12 последовательных if-блоков, каждый из которых учитывал комбинацию типа груза, региона, клиента, времени суток, дня недели, веса и габаритов. Логика была написана десять лет назад и постепенно расширялась: каждое новое требование от бизнеса добавляло один-два условия «в самый низ».

Проблемы:

• Любое изменение — например, введение скидки для постоянных клиентов в выходные — требовало 3–5 дней анализа, чтобы не нарушить существующие правила.
• Тестировщики находили регрессии в 40 % релизов, связанных с этим модулем.
• Ни один джуниор не смел трогать код без сопровождения архитектора.

Решение:
Команда провела реструктуризацию по принципу табличных политик. Была введена доменная модель PricingRule, содержащая предикат (функцию, определяющую применимость правила к заказу) и действие (функцию расчёта). Все 12 условий были вынесены в JSON-конфигурацию, загружаемую при старте. Ядро свелось к:

var applicableRules = rules.Where(r => r.Predicate(order)).OrderByDescending(r => r.Priority);
return applicableRules.First().Calculate(order);

Сложность ядра упала до 3. Общая логическая сложность системы не исчезла — она переместилась в данные, где её стало проще тестировать (тесты стали таблицами вход → выход), документировать (правила стали читаемы менеджерами) и изменять (без деплоя).

Результат:

• Время внедрения нового правила — от 2 часов (редактирование JSON + тест) до 1 дня (если требовалась новая сигнатура предиката).
• Число регрессий в модуле — 0 за 18 месяцев.
• Документация по тарифам перестала быть «описанием кода» и превратилась в описание бизнес-правил.

Кейс 2. Валидация входных форм в государственной информационной системе

В одном из сервисов приёма заявлений от граждан метод ValidateApplication имел сложность 94. Условия включали проверку полей в зависимости от типа заявления (17 типов), региональных особенностей (84 субъекта РФ), возраста заявителя, наличия льгот и других параметров. Многие условия дублировались или частично пересекались.

Особенность: изменения в валидации требовали прохождения экспертизы в регуляторном органе — каждая правка кода влекла месяцы согласований.

Подход:
Команда реализовала гибридную модель — валидация на основе доменных событий. Вместо прямой проверки условий, входные данные трансформировались в поток событий: ApplicantIsMinor, RegionIsMoscow, DocumentTypeIsPassport и т.д. Правила валидации стали реактивными подписчиками на комбинации событий, реализованными через паттерн Specification.

Например:

var rule = new AndSpecification<ApplicantContext>(
    new IsMinorSpecification(),
    new RegionSpecification("77"),
    new DocumentTypeSpecification(DocumentType.BirthCertificate)
);
rule.IsSatisfiedBy(context); // → требует дополнительное поле «СНИЛС родителя»

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

Результат:

• Новые требования теперь формулировались бизнес-аналитиками на языке событий и спецификаций, а не на языке if.
• Тесты стали параметризованными: одна реализация Specification — десятки комбинаций входных данных.
• Срок согласования изменений сократился втрое: эксперты проверяли не код, а декларативные правила.

Кейс 3. Обработка событий в интеграционной шине

В микросервисной архитектуре один из обработчиков событий (OnOrderStateChanged) показывал регулярные задержки и периодические падения. Анализ выявил сложность 38 — обработчик содержал цепочку из 9 switch по статусу заказа, внутри каждого — вложенные if по типу клиента, способу оплаты и наличию промокода.

Антипаттерн: логика распределения была встроена в логику обработки.

Решение:
Внедрена двухуровневая маршрутизация:

1. Сначала — диспетчер, выбирающий нужный обработчик по комбинации EventType + OrderStatus + CustomerTier. Его сложность — 4.
2. Затем — специализированный обработчик состояния, реализующий только одну сценарию: HandlePaidOrderForVipCustomer.

Разбиение потребовало введения фабрики обработчиков и контракта IOrderStateHandler, но позволило:

• Убрать 97 % дублирования кода (ранее один и тот же блок «отправить email» повторялся 6 раз).
• Ввести контрактные тесты на каждый обработчик независимо.
• Отказаться от монолитного лога в пользу структурированной трассировки по handler_id.

Сложность каждого обработчика — 2–7. Общая поддерживаемость возросла на порядок.

Эти кейсы демонстрируют одну общую мысль: снижение цикломатической сложности — это перепроектирование взаимодействия между людьми, процессами и кодом. Успех определяется готовностью перейти от реализации логики к моделированию домена.

---

Как внедрить контроль сложности в команду

Внедрение метрики «с нуля» требует системного подхода. Ниже — проверенная практика, разбитая на фазы.

Фаза 1. Диагностика и осознание (2–4 недели)

• Запустите анализ всей кодовой базы с помощью выбранного инструмента.
• Постройте распределение: гистограмма количества методов по интервалам сложности (1–5, 6–10, 11–20, >20).
• Выделите топ-10 методов по абсолютному значению и топ-5 модулей по средней сложности.
• Презентуйте результаты команде как «карту состояния». Спросите: «С какими из этих модулей вы сталкиваетесь чаще всего? Где теряете время?»

Фаза 2. Установка целевых порогов (1 неделя)

• Определите жёсткий лимит (например, 20 — запрещено без исключения) и целевой порог (например, 10 — рекомендовано для новых методов).
• Уточните исключения: генерируемый код, парсеры, алгоритмы с доказанной сложностью (например, сортировки).
• Зафиксируйте правила в Кодексе культуры кода как инженерный договор.

Фаза 3. Интеграция в CI/CD (1–2 спринта)

• Настройте автоматическую проверку в пайплайне:
  • Новые методы с complexity > целевого порога — предупреждение.
  • Новые методы с complexity > жёсткого лимита — ошибка сборки (если не помечены // SUPPRESS-COMPLEXITY: причина).
• Добавьте тренд: график медианной сложности по релизам. Цель — снижение или стабилизация.

Фаза 4. Обучение и практика (постоянно)

• Проведите воркшоп: «Как разбить метод со сложностью 25 за 45 минут». Разберите реальный пример из кодовой базы.
• Введите правило: на код-ревью, если сложность >10, требуется объяснение архитектурного выбора.
• Включите метрику в гайдлайн для докладов на внутренних митапах: «Покажи, как ты снижал сложность в своей задаче».

Фаза 5. Обратная связь и адаптация

• Через 3 месяца проведите опрос:
  • «Стало ли проще вносить изменения в модули, где мы снизили сложность?»
  • «Уменьшилось ли время на поиск причин регрессий?»
• Обновите пороги, если они оказались нереалистичными (слишком высокими — нет эффекта; слишком низкими — накладные расходы).

Метрика должна служить, а не управлять. Её задача — делать невидимое видимым, давать аргументы для решений, а не заменять профессиональное суждение.

---