scan4llm/.ai/SOLID_AUDIT.md

SOLID/DRY/KISS/YAGNI Audit

Периодический аудит кода по принципам SOLID, DRY, KISS, YAGNI.

Когда запускать

• После реализации крупной фичи (>200 строк нового кода)
• Перед финальным тестированием этапа
• При рефакторинге
• Когда файл превышает 300 строк

Категории проверки

YAGNI — код, который не используется

• Функции/классы без вызовов
• Импорты без использования
• Параметры, которые всегда передаются с одним значением
• Return-значения, которые игнорируются ВСЕМИ вызывающими

DRY — дублирование

• Идентичные блоки кода в разных файлах (ctrl-c/ctrl-v)
• Одинаковая логика с разными именами
• Дублирование _load_env, шаблонов, моделей данных
• Повторяющиеся импорты внутри функции/модуля

KISS — излишняя сложность

• Вложенность >3 уровней
• Функции >40 строк без явной причины
• Сложная арифметика там, где есть библиотечная функция
• Типы Any там, где известна структура
• Magic numbers вместо именованных констант

SRP — смешение ответственности

• Функция делает ≥3 логически разных действий
• Модуль импортирует несвязанные библиотеки
• Класс/функция и генерирует данные, и форматирует, и сохраняет

Связность (Coupling)

• Глобальные переменные-синглтоны
• Прямые импорты конкретных реализаций вместо протоколов
• Жёсткая привязка к путям в ФС (/home/user/...)

Обработка ошибок

• Нет try/except вокруг внешних вызовов (сеть, диск, API)
• assert для control flow
• Строковые срезы без проверки на find() == -1

Процесс

1. Пройти по всем src/*.py сверху вниз
2. Для каждого файла отметить проблемы с номером строки
3. Сгруппировать по категориям
4. Приоритезировать: bug > DRY > YAGNI > style
5. Исправлять от высокого приоритета к низкому

Что НЕ является проблемой (не чинить)

• Ленивые импорты внутри функций (для избежания циклических зависимостей)
• Синглтоны для тяжёлых объектов (ML-модели, pipeline’ы) — оправдано производительностью
• Кодогенерация/шаблоны — читаемость важнее «чистоты» строк