Оцените качество кодовой базы баллом от 0 до 100
Глубокий аудит кодовой базы: механический анализ + экспертная оценка архитектуры, элегантности, типобезопасности и тестового покрытия. Выдаёт числовой балл и приоритизированный план улучшений.
Как агент работает
Аудит смотрит не на дифф, а на кодовую базу целиком и заканчивается одним числом от 0 до 100, собранным из двух пулов: механического на 25% и субъективного на 75%. Ключевой принцип модели — улучшение балла обязано коррелировать с улучшением кода, поэтому перед выдачей числа проходит шаг антиманипуляционных проверок: балл, который легко накрутить без реальных правок, бесполезен.
Механический пул — пять измерений с весами: здоровье файлов с весом 2.0 (файлы длиннее 300 строк, директории больше 15 файлов, мёртвые файлы, нарушения конвенций именования) и по единице у качества кода, дупликации, здоровья тестов и безопасности. Проверяются пустые catch, цикломатическая сложность выше 10, вложенность глубже 4 уровней, debug-логи в проде, дублированные блоки длиннее 6 строк, тесты уровня assert True.
Субъективный пул — двенадцать измерений, где элегантность высокого и среднего уровня весят по 22, низкого уровня, когерентность контрактов и типобезопасность — по 12, когерентность дизайна — 10, дальше уместность абстракций, ясность логики, структура и навигация, консистентность ошибок, качество нейминга и AI-сгенерированный долг с весом 1. Шкала прозрачна: 90–100 — образцовый код, 50–69 — средне, ниже 30 — каждое изменение рискует что-то сломать.
Каждая находка получает тир от T1 «авто-фикс» до T4 «рефакторинг», уверенность HIGH 1.0, MEDIUM 0.7 или LOW 0.3 и привязку к одному из 17 измерений — из этого собираются топ-10 проблем по влиянию на балл, список пяти главных тормозов и план на три горизонта: немедленно, ближайший спринт и стратегически, с ожидаемым приростом по каждому. Аудит выдаёт диагноз и план, но правки в код не вносит и решение о приёмке работы не принимает.
Аудит качества кода
Философия
Ключевой принцип: улучшение балла должно реально коррелировать с улучшением кода. Балл, который легко накрутить без реальных улучшений — бесполезен.
Модель скоринга
Итоговый балл = 25% механический + 75% субъективный (шкала 0–100).
Механический пул (25% итогового балла)
Пять измерений с весами:
| Измерение | Вес | Что проверяем |
|---|---|---|
| Здоровье файлов | 2.0 | Размер файлов, количество файлов в директориях, мёртвые файлы, нейминг |
| Качество кода | 1.0 | Мёртвый код, code smells, неиспользуемые импорты/переменные/функции, сложность |
| Дупликация | 1.0 | Повторяющиеся блоки, бойлерплейт, скопированная логика |
| Здоровье тестов | 1.0 | Покрытие, качество тестов, детерминированность, граничные случаи |
| Безопасность | 1.0 | Инъекции, утечки секретов, небезопасная криптография, SSRF, XSS |
Формула для каждого измерения:
Вес ошибки зависит от уверенности: HIGH = 1.0, MEDIUM = 0.7, LOW = 0.3.
Субъективный пул (75% итогового балла)
Двенадцать измерений с весами:
| Измерение | Вес | Что оцениваем |
|---|---|---|
| Высокоуровневая элегантность | 22 | Архитектура системы в целом: разделение ответственности, граф зависимостей, потоки данных. Мог бы новый инженер понять систему за день? |
| Среднеуровневая элегантность | 22 | Модули и компоненты: связность внутри, слабая связанность между. Есть ли чёткие контракты на границах модулей? |
| Низкоуровневая элегантность | 12 | Функции и методы: длина, вложенность, цикломатическая сложность. Читается ли код сверху вниз без прыжков? |
| Когерентность контрактов | 12 | Согласованность интерфейсов, API, типов между модулями. Одинаковые данные представлены одинаково? |
| Типобезопасность | 12 | Строгость типизации, отсутствие any/unknown escape-хатчей, правильные дженерики и guard-клаузы |
| Когерентность дизайна | 10 | Единообразие паттернов: если ошибки обрабатываются через Result — везде ли? Если state через хуки — везде ли? |
| Уместность абстракций | 8 | Нет ли преждевременных абстракций? Нет ли недо-абстракций (3+ копии одной логики)? Каждая абстракция оправдана реальным переиспользованием? |
| Ясность логики | 6 | Можно ли понять бизнес-логику, не заглядывая в соседние файлы? Guard clauses вместо глубокой вложенности? |
| Структура и навигация | 5 | Организация файлов/папок: можно ли найти нужный код по названию? Есть ли паттерн в расположении? |
| Консистентность ошибок | 3 | Единый подход к ошибкам: одинаковые коды, форматы сообщений, стратегии обработки |
| Качество нейминга | 2 | Имена переменных, функций, типов передают намерение. Нет сокращений без контекста, нет generic имён (data, info, item, handle) |
| AI-сгенерированный долг | 1 | Признаки генерации без ревью: одинаковые комментарии-заглушки, избыточная обработка невозможных ошибок, over-engineering простых задач |
Процедура аудита
Шаг 2: Механический анализ
Для каждого из 5 механических измерений выполни проверки:
Здоровье файлов (вес 2.0)
- Файлы > 300 строк — кандидаты на разбиение
- Директории > 15 файлов — нужны поддиректории
- Мёртвые файлы (не импортируются, не используются)
- Нарушения конвенции нейминга файлов
- Плоские директории без структуры
Качество кода (вес 1.0)
- Неиспользуемые импорты, переменные, параметры
- Неиспользуемые экспорты / функции / классы
- Пустые блоки catch/except без обработки
- Мёртвые ветки (unreachable code)
- Цикломатическая сложность > 10
- Глубокая вложенность > 4 уровней
- Debug-логи в продакшн-коде (console.log, print, debugger)
- Закомментированный код
Дупликация (вес 1.0)
- Дублированные блоки кода (> 6 строк)
- Повторяющийся бойлерплейт между файлами
- Скопированная бизнес-логика вместо переиспользования
- Одинаковые паттерны обработки ошибок, которые можно обобщить
Здоровье тестов (вес 1.0)
- Непокрытые критические пути (happy path + основные ошибки)
- Тесты, проверяющие реализацию, а не поведение
- Недетерминированные тесты (зависят от времени, порядка, сети)
- Моки, скрывающие реальные проблемы
- Отсутствие тестов на граничные случаи
- Пустые или тривиальные тесты (assert True)
Безопасность (вес 1.0)
- SQL-инъекции (конкатенация строк вместо параметризации)
- XSS (вставка пользовательских данных без экранирования)
- Секреты в коде (API-ключи, пароли, токены)
- Отсутствие валидации входных данных на границах API
- Небезопасная криптография (MD5, SHA1 для паролей)
- SSRF (запросы по пользовательским URL без проверки)
- Избыточные права доступа / отсутствие проверок авторизации
Шаг 3: Субъективная оценка
Для каждого из 12 субъективных измерений:
Шкала субъективной оценки:
- 90–100: Образцовый код, можно показывать как пример
- 70–89: Хорошо, есть куда расти, но основа крепкая
- 50–69: Средне, заметные проблемы, но код рабочий
- 30–49: Ниже среднего, накопленный техдолг мешает развитию
- 0–29: Критично, код хрупкий, каждое изменение рискует что-то сломать
Шаг 4: Классификация находок
Каждой найденной проблеме присвой:
Тир (серьёзность):
| Тир | Название | Вес | Описание |
|---|---|---|---|
| T1 | Авто-фикс | 1 | Тривиально исправить: удалить импорт, убрать лог, форматирование |
| T2 | Быстрый фикс | 2 | Простое ручное исправление: переименовать, добавить валидацию, исправить тип |
| T3 | Требует решения | 3 | Нужна инженерная оценка: разбить файл, выделить модуль, пересмотреть контракт |
| T4 | Рефакторинг | 4 | Значительная переработка: изменить архитектуру модуля, пересмотреть flow данных |
Уверенность: HIGH (1.0) / MEDIUM (0.7) / LOW (0.3)
Измерение: К какому из 17 измерений относится находка.
Шаг 5: Антиманипуляционные проверки
Перед выдачей финального балла проверь себя:
Формат отчёта
Механические измерения
Таблица с баллами по каждому из 5 измерений:
| Измерение | Балл | Проверок | Проблем | Тяжесть |
|---|---|---|---|---|
| Здоровье файлов | XX/100 | N | N | T1:N T2:N T3:N T4:N |
| Качество кода | XX/100 | N | N | ... |
| Дупликация | XX/100 | N | N | ... |
| Здоровье тестов | XX/100 | N | N | ... |
| Безопасность | XX/100 | N | N | ... |
Субъективные измерения
Таблица с баллами по каждому из 12 измерений:
| Измерение | Балл | Уверенность | Главная проблема |
|---|---|---|---|
| Высокоуровневая элегантность | XX | HIGH/MED/LOW | Краткое описание |
| Среднеуровневая элегантность | XX | ... | ... |
| ... | ... | ... | ... |
Топ-проблемы (отсортированы по влиянию на балл)
Для каждой из 10 самых влиятельных проблем:
Самые большие тормоза балла
Список из 5 измерений, которые больше всего тянут балл вниз, с расчётом:
Приоритизированный план действий
Три горизонта:
Немедленно (T1–T2, рост балла +N)
Пронумерованный список конкретных действий, которые можно выполнить за 1 сессию.
Ближайший спринт (T2–T3, рост балла +N)
Задачи, требующие инженерной оценки, но выполнимые за 1–2 дня.
Стратегически (T3–T4, рост балла +N)
Архитектурные изменения, требующие планирования.
Адаптация под стек
Python
- Аннотации типов (mypy strict), dataclasses vs pydantic
- Async/await корректность, отсутствие блокирующих вызовов в async-контексте
- Импорты: абсолютные vs относительные, циклические зависимости
TypeScript / JavaScript
- Строгость tsconfig (strict: true), отсутствие any
- React: правильные зависимости хуков, мемоизация, разделение компонентов
- Next.js: RSC/client boundary, правильный fetching, нет env-утечек
Go
- Обработка ошибок (не игнорировать), горутин-менеджмент
- Интерфейсы: маленькие, в месте использования
- Context propagation, graceful shutdown
Rust
- Обработка ошибок: Result вместо panic, thiserror/anyhow
- Ownership: минимум clone(), правильные lifetimes
- Unsafe: обоснован и задокументирован
SQL / Миграции
- Параметризация, индексы, обратимость миграций
- N+1 проблемы, денормализация vs производительность
Похожие навыки
Попробуйте этот навык
Зарегистрируйтесь и используйте навык «Аудит качества кода» бесплатно.