# 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'ы) — оправдано производительностью
- Кодогенерация/шаблоны — читаемость важнее «чистоты» строк