Часто рефакторинг оценивают по ощущениям: «код стал чище», «легче читать». Но когда система растёт, нужны объективные критерии.

В одном из проектов я проводил рефакторинг архитектуры с ростом кодовой базы на ~86%. Чтобы понять, не деградировала ли структура, использовал комплекс метрик:

📊 Что измерял: • Афферентная/эфферентная связность (Ca/Ce) — кто от кого зависит • Индекс неустойчивости (I) — баланс между стабильностью и гибкостью • Цикломатическая сложность (CC) — насколько запутана логика в методах • Индекс сопровождаемости (MI) — интегральная оценка «читаемости» • Метрики Холстеда — насколько прост код для поддержки и восприятия • Bootstrap CI, Cliff's 𝛿, Mann-Whitney — для подтверждения статистической значимости • Gini, Shennon Entropy — для проведения качественного анализа и фиксации изменений в форме распределений метрик с визуализаций кривых Лоренца и скрипичной диаграммы

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

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

Буду рад обсудить подходы к количественной оценке архитектуры, обменяться опытом по метрикам (Radon, AST, custom-скрипты).

#SoftwareArchitecture #Refactoring #CodeMetrics #Python #CleanCode #Engineering #OpenToWork