Рефакторинг кодовой базы

Ты — ревьюер кода. Проведи анализ кодовой базы в текущей папке. Цель — составить объективную картину состояния кода ПЕРЕД рефакторингом.

## Что проверить

Оцени каждую из 6 категорий ниже. Для каждой поставь оценку и приведи конкретные примеры.

### 1. Структура проекта
Логична ли организация файлов и папок? Понятно ли где что искать? Есть ли файлы, которые лежат не на своём месте?

### 2. Дублирование
Найди повторяющийся код (одинаковая или почти одинаковая логика в 2+ местах). Для каждого случая укажи: где дублируется и куда можно вынести.

### 3. Сложность
Функции/модули, которые делают слишком много (> 1 ответственности). Длинные функции (> 50 строк). Глубокая вложенность (> 3 уровней if/for).

### 4. Именование
Неинформативные имена (data, result, tmp, handler2). Несогласованные конвенции (camelCase вперемешку с snake_case). Аббревиатуры без контекста.

### 5. Отсутствующая документация
Места, где код неочевиден, но комментария нет. Публичные API без описания параметров. Неочевидные side-effects.

### 6. Мёртвый код
Неиспользуемые функции, переменные, импорты. Закомментированный код. Файлы-сироты.

## Формат ответа

Для каждой категории:

| Категория | Оценка | Примеры |
|---|---|---|
| Структура | хорошо / требует улучшения / критично | конкретные файлы/модули |
| ... | ... | ... |

В конце — общий вердикт в 2-3 предложениях: главные проблемы и сильные стороны.

На основе анализа из предыдущего шага составь приоритизированный план рефакторинга.

## Формат для каждого улучшения

| Поле | Описание |
|---|---|
| **Что** | Конкретный файл, функция или модуль |
| **Проблема** | Почему текущее состояние плохо: риск ошибок / сложность поддержки / дублирование / нечитаемость |
| **Решение** | Как исправить — одно предложение, конкретное действие |
| **Риск** | Низкий (косметика, без изменения поведения) / Средний (меняет внутреннюю структуру) / Высокий (меняет интерфейсы, может сломать зависимый код) |
| **Трудозатраты** | Минуты / Часы / Полдня |
| **Зависимости** | Какие другие пункты нужно сделать раньше (или «нет») |

## Сортировка

Отсортируй по приоритету: сначала высокое влияние + низкий риск. Пронумеруй каждый пункт — нумерация понадобится на следующем шаге.

## Ограничения
- Не включай изменения ради изменений: каждый пункт должен решать конкретную проблему из анализа
- Если улучшение требует сначала обсуждения архитектурного решения — отметь как ТРЕБУЕТ ОБСУЖДЕНИЯ
- Максимум 15 пунктов. Если нашёл больше — оставь топ-15 по приоритету, остальные упомяни одной строкой в конце

Выполни рефакторинг по плану из предыдущего шага. Начни с пунктов с низким риском.

## Порядок работы

1. Назови номер и название пункта из плана, который будешь выполнять
2. Опиши что сейчас изменишь (1-2 предложения)
3. Сделай изменение
4. Кратко подтверди: что сделано, какие файлы затронуты
5. Жди моей команды «продолжай» перед следующим пунктом

## Правила (нарушение любого = остановка)

- **Одно изменение за раз.** Не группируй несколько пунктов в одно изменение
- **Поведение кода не меняется.** Рефакторинг = структура и читаемость, не логика. Если уверен что тесты покрывают изменение — скажи об этом
- **Высокий риск = предупреждение ДО изменения.** Если пункт отмечен как средний/высокий риск, сначала объясни что может сломаться и как проверить. Жди подтверждения
- **Баги не чинить.** Если обнаружил баг по ходу — запиши в отдельный список в конце. Не исправляй в рамках рефакторинга
- **Не добавлять ничего нового.** Никаких новых зависимостей, абстракций, паттернов, которых не было в плане

## Начни

Выполни первые 3 пункта из плана (по одному, с ожиданием «продолжай» после каждого). В конце выведи:
- Сколько пунктов выполнено
- Какие пункты остались
- Обнаруженные баги (если были)