Разбор · Опубликовали 08.10.2026
Цикломатическая сложность показывает, сколько ветвлений агент добавил в критичную функцию
Как сравнить функцию до и после правки ИИ-агента, проверить новое условие и принять код. На учебном примере и поломках машины vibecoding.ru; собственного замера сложности и клиентского кейса у нас нет.
Текст собран инженером, который ведёт vibecoding.ru, вместе с машиной агентов · факты проверены 8 октября 2026
Цикломатическая сложность кода помогает заметить новые развилки в критичной функции до принятия правки ИИ-агента.
Чтобы решить, пропускать ли правку, сравните число до и после, назовите добавленное условие и свяжите его со сценариями проверки.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Разница до и после показывает новые точки решения.
Условие заставляет функцию выбрать следующий шаг. Цикломатическая сложность считает линейно независимые пути по графу её управления.
В учебной функции два if: отказ без оплаты и отказ после окончания срока. Если оба условия ложны, доступ открыт. Сложность 3.
Агент добавляет ещё один отказ: заказ отменён. Теперь сложность 4, прирост 1. Это новая точка решения, и её поведение нужно включить в границу задачи для агента.
Одно новое условие увеличивает сложность учебной функции с 3 до 4.
Учебная функция с ранним возвратом при каждом отказе, без других ветвлений. Ручной счёт по NIST SP 500-235, §4.1; проверено 08.10.2026. Это не замер репозитория.
2. Сравнение имеет смысл при одинаковом способе подсчёта.
Единого предела для всех организаций нет, говорит Microsoft Learn. Даже небольшое число не разрешает выдавать доступ отменённому заказу.
Ветвления есть и без if. По текущему ESLint запись a?.b?.c добавляет две ветви. Значения по умолчанию тоже участвуют в счёте.
Сравнивайте числа одной версией анализатора и одинаковыми настройками. После его обновления рост может объясняться способом счёта.
Число осталось прежним? Агент мог добавить условие и убрать другое. Сверьте саму правку: разница показывает чистый прирост, а не список новых условий.
В отчёте должны совпадать инструмент, настройки и граница функции.
ESLint complexity и Microsoft Learn, проверено 08.10.2026. Сопоставимость замеров является нашим методическим выводом.
3. Зелёное число не проверяет данные и договор функции.
Метрика описывает выбор пути. А проверки входов, выходов и взаимодействий показывают, получила ли система нужные данные и выполнила ли правило продукта.
На vibecoding.ru инженер ведёт машину агентов, её работа видна в открытом приборе машины. Вот две поломки, для которых понадобились отдельные проверки.
Сложность этих функций мы не измеряли. Четыре маршрута поля между функциями не равны сложности одной функции. Это истории о пропущенных проверках.
Проверки появились после конкретных поломок.
31.07
Поле сцены обложки терялось на двух из четырёх путей передачи новости. Сделали общий сборщик полей; проверка ловит его обход.
24.09
Функция возвращала новое поле, которого не было в проверке формы ответа; некэшированные страницы новостей падали. Добавили тест соответствия ответа его валидатору.
Исходные записи журналов машины за 31.07 и 24.09.2026, перечитаны 08.10.2026. Это истории проверки данных и контракта, не измерения цикломатической сложности.
4. Новое условие проверяют вместе со старыми сценариями.
Оплаченный заказ бывает отменённым. Для нового условия нужно назвать ожидаемый результат при таком сочетании, а затем проверить его.
Сложность 4 не означает, что достаточно четырёх тестов. NIST дополняет проверку независимых путей проверками требований и граничных данных.
Проверьте новый отказ и прежнее разрешение. Повторные вызовы и ответ для соседнего модуля тоже входят в приёмку; проверки и откат выбирают по цене ошибки.
Отмена заказа должна закрывать доступ, не ломая прежнее разрешение.
Сценарии нашего учебного примера, 08.10.2026. Это предложение для приёмки конкретного правила доступа, не универсальный тест-план и не клиентский результат.
5. Рост сложности становится предметом проверки каждой правки.
Начните с изменённой функции. Сохраните исходное число рядом с версией кода, измерьте заново после правки и попросите объяснить рост.
В правилах для агента закрепите пакет приёмки: причина ветвления и результаты проверок. Ревьюер сверяет их с требованием задачи.
Число снизилось после переноса условия в помощник? Проследите правило целиком: функция стала короче, но решение осталось в системе.
Правку принимают вместе с причиной роста и результатом проверок.
Редакционная схема приёмки, 08.10.2026, на основе определения метрики и метода NIST. Универсальный числовой порог не предлагается.
6. Первая задача заканчивается проверенной функцией.
Выберите функцию, где ошибка меняет деньги или доступ. Её сравнение и проверки составят первую задачу. Общая система ждёт разбора технического долга.
Если некому вести задачу, подписка на агентную разработку «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026.
В одном потоке одновременно работает одна задача. Разбор ветвлений и проверок можно включить в задачу изменения функции.
Для обсуждения задачи есть вход для руководителя. Подготовьте требование к функции и пример результата, который нельзя допустить.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Определение метрики | ESLint и NIST SP 500-235: линейно независимые пути в графе управления. Их число не равно всем сочетаниям входных данных | 2026-10-08 |
| Учебные 3 и 4 | Ручной счёт по NIST §4.1. Два бинарных if с ранним отказом дают 1 + 2 = 3; третье условие даёт 1 + 3 = 4. Других ветвлений в примере нет. Это не анализ нашего репозитория | 2026-10-08 |
| Пределы и инструмент | Microsoft Learn не устанавливает общего ограничения для всех организаций. Правило ESLint complexity описывает дополнительные ветви в optional chaining и варианты classic и modified | 2026-10-08 |
| Наши поломки | Исходные записи журналов 31.07 и 24.09.2026 перечитаны. Два из четырёх маршрутов поля и несовпадение ответа с валидатором подтверждены. Значения сложности этих функций не измерены | 2026-10-08 |
| Цена и поток | Живая /services: «Один проект», 250 000 ₽ в месяц, один поток; одновременно работает одна задача. Снято 08.10.2026, 04:29 МСК. Это оффер, не клиентский результат | 2026-10-08 |
| Границы доказательств | Собственного замера цикломатической сложности и клиентского кейса нет. Опорные тезисы проверены отдельным скептиком по первоисточникам. Таблицы сценариев и шагов являются редакционной рекомендацией | 2026-10-08 |
7. Частые вопросы
Почему метрика называется цикломатической?+
Название относится к свойству графа управления, введённому в методе Маккейба. В задаче CTO полезен практический смысл: насколько выросло число независимых путей внутри изменённой функции.
Чем цикломатическая сложность отличается от длины функции?+
Длина считает строки, сложность отражает решения. Дополнительные обычные операции способны удлинить функцию без роста метрики.
Как измерить сложность TypeScript-кода?+
Анализатором, который поддерживает синтаксис проекта. В ESLint есть правило complexity. Для сравнения сохраняют версию инструмента и его настройки вместе с результатом.
Надо ли отклонять любое увеличение?+
Нет. Новое требование способно добавить обоснованное условие. Принимающий должен увидеть его назначение и проверки, а решение зависит от критичности функции.
Можно ли оценить качество агента этим числом?+
По одному числу нельзя. На результат влияет сама задача, способ счёта и перенос логики между функциями. Без сопоставимых задач и проверки поведения вывод об агенте не подтверждён.
Источники
- ESLint, правило complexity · проверено 08.10.2026 — официальная документация
- Watson и McCabe, Structured Testing, NIST SP 500-235 (1996), §4.1 и §5.6 · проверено 08.10.2026 — первичная методология
- Microsoft Learn, Code metrics: Cyclomatic complexity · проверено 08.10.2026 — официальная документация
- Публичная машина vibecoding.ru; истории 31.07 и 24.09 сверены по исходным записям · проверено 08.10.2026 — наш опыт, без замера сложности
- vibecoding.ru, тариф «Один проект» и один поток работы · проверено 08.10.2026 — наш оффер
Запомнить
1. Сравнивайте одну функцию до и после правки одинаковым анализатором.
2. Свяжите каждое новое условие с требованием задачи.
3. Проверяйте новый сценарий вместе со старыми и граничными данными.
4. Число сложности не доказывает правильность ответа или передачи полей.
5. Принимайте правку по объяснённому изменению и результатам проверок.