ИИ для рефакторинга кода

📋 Стратегия рефакторинга без остановки разработки:

Правило: рефакторинг параллельно с фичами, не вместо.

Каждый PR включает: фича (80% времени) + рефакторинг затронутого модуля (20%). Через 3 месяца — 60% кода чистый.

Приоритизация (по метрике «боль × частота изменений»):

1. UserController (2 100 строк, меняется 3 раза/неделю) — ПЕРВЫЙ
2. OrderService (1 800 строк, меняется 2 раза/неделю)
3. PaymentModule (1 200 строк, меняется 1 раз/неделю)
4-10. Остальные модули по убыванию частоты изменений

Подход «Strangler Fig» (постепенная замена):
• Не переписываем модуль целиком
• Создаём новый чистый модуль рядом со старым
• Перенаправляем запросы по одному
• Когда 100% запросов идут в новый — удаляем старый

Неделя 1 — начать с тестов:
Покрыть integration-тестами 3 критических пути:
• Регистрация + авторизация
• Создание заказа + оплата
• Основной CRUD

Это страховочная сетка для дальнейшего рефакторинга. Без неё — опасно.

Начнём с UserController — скинь код?

♻️ Декомпозиция UserController (2 100 строк → 9 модулей):

Текущие ответственности (7 штук в одном файле):
1. Регистрация/авторизация — 450 строк
2. Профиль (CRUD) — 320 строк
3. Аватарки (загрузка, ресайз) — 280 строк
4. Подписки (follow/unfollow) — 350 строк
5. Поиск пользователей — 200 строк
6. Админка (блокировка, роли) — 300 строк
7. Общий код (валидация, форматирование) — 200 строк

Новая структура:
```
controllers/
AuthController.js — 120 строк (register, login, logout, refresh)
ProfileController.js — 80 строк (get, update, delete)
AvatarController.js — 70 строк (upload, delete)
FollowController.js — 90 строк (follow, unfollow, followers, following)
UserSearchController.js — 60 строк (search, suggest)
AdminUserController.js — 80 строк (block, unblock, setRole)

services/
AuthService.js — 150 строк (бизнес-логика авторизации)
UserService.js — 100 строк (CRUD пользователей)
FollowService.js — 120 строк (логика подписок)
```

Порядок миграции (по 1 контроллеру за PR):
PR 1: AuthController (самый критичный)
PR 2: ProfileController + UserService
PR 3: AvatarController
PR 4: FollowController + FollowService
PR 5: UserSearchController
PR 6: AdminUserController
PR 7: Удаление старого UserController

2 100 строк → 870 строк в 9 файлах. Каждый файл < 150 строк. Начать с AuthController?

📋 Пошаговая миграция jQuery → React (без простоя):

Стратегия: «Islands Architecture» → постепенная замена

Не переписываем весь сайт. Встраиваем React-компоненты в существующие Blade-страницы. Постепенно заменяем, пока не останется чистый React.

Фаза 1 (неделя 1-2): Инфраструктура
• Настроить Vite + React внутри существующего Laravel
• Один React-компонент в Blade: ``
• REST API для компонентов, которые будем мигрировать
• Без изменения UX — пользователь ничего не заметит

Фаза 2 (неделя 3-6): Интерактивные «острова»
• Корзина (React) — самый интерактивный блок
• Фильтры каталога (React) — сложная логика на jQuery
• Модальные окна (React) — повторяются на многих страницах
• Остальная страница — по-прежнему Blade + jQuery

Фаза 3 (неделя 7-12): Целые страницы
• Каталог → React SPA (крупнейший блок)
• Личный кабинет → React SPA
• Checkout → React SPA

Фаза 4 (неделя 13-16): Полная миграция
• Главная, статичные страницы, SEO-страницы
• Удаление jQuery и Blade
• SSR через Next.js для SEO

Каждая фаза — отдельный деплой. Откат — мгновенный (переключение маршрута).

Начнём с корзины — покажи текущий jQuery-код?

♻️ Миграция корзины: jQuery (600 строк) → React (280 строк):

Было (jQuery, проблемы):
• Состояние хранится в DOM: `$('.cart-count').text()`
• 34 прямых DOM-манипуляции
• Ajax без обработки ошибок и состояния загрузки
• Нет оптимистичного обновления — кнопка «зависает»

Стало (React):
```
components/
Cart/
Cart.tsx — 45 строк (контейнер)
CartItem.tsx — 35 строк (один товар)
CartSummary.tsx — 25 строк (итого + кнопка)
CartEmpty.tsx — 15 строк (пустая корзина)
hooks/
useCart.ts — 80 строк (логика: add, remove, update, fetch)
api/
cartApi.ts — 40 строк (REST-запросы)
types/
cart.ts — 20 строк (TypeScript интерфейсы)
```

Улучшения «бесплатно»:
• Оптимистичное обновление: кнопка «+» мгновенно меняет цифру
• Skeleton при загрузке вместо зависшей страницы
• Debounce при изменении количества (не 10 запросов в секунду)
• TypeScript — ошибки ловятся до рантайма

600 строк → 280 строк. 0 прямых DOM-манипуляций. Типизация. Тесты написать?

📋 Квартальный план снижения техдолга:

Метрики (измерять еженедельно):
• Cycle time: время от начала задачи до деплоя (текущий: 8 дней → цель: 4)
• Bug rate: баги на 100 коммитов (текущий: 12 → цель: 5)
• Code coverage: тесты (текущий: 18% → цель: 50% для критических модулей)
• Tech debt ratio: SonarQube (текущий: 23% → цель: 10%)

Месяц 1 — Фундамент:
• Неделя 1-2: CI/CD + линтеры + автоформатирование (black, isort, eslint)
• Неделя 3-4: Тесты на 5 критических модулей (авторизация, оплата, подписки, API, поиск)
• Правило: каждый PR с фичей включает 20% рефакторинга затронутого кода

Месяц 2 — Ключевые модули:
• Декомпозиция 3 God Objects (UserService, OrderService, SubscriptionService)
• Миграция с class-based views на DRF ViewSets (единообразие)
• React: выделение shared-компонентов (сейчас 30% дублей в UI)

Месяц 3 — Оптимизация:
• N+1 запросы: select_related/prefetch_related (найдено 47 проблемных мест)
• Dead code removal (SonarQube показывает 8 000 строк мёртвого кода)
• Обновление зависимостей (Django 3.2 → 5.0, React 17 → 18)

Распределение: 4 разработчика = 80% фичи + 20% рефакторинг. 1 разработчик (ротация) = 100% техдолг.

Начать с аудита самого «больного» модуля?

🔬 Аудит OrderService.py (3 400 строк):

Метрики:
• Методов: 67 (норма: 10-15)
• Средняя длина метода: 51 строка (норма: 15-20)
• Цикломатическая сложность: 94 (критический уровень)
• Покрытие тестами: 4% (2 теста из ~50 нужных)

🔴 Топ-5 проблем (порядок починки):

1. create_order() — 380 строк, 14 if/else
Содержит: валидацию, расчёт цены, работу со складом, оплату, уведомления, логирование
→ Декомпозиция на 7 методов + OrderPipeline

2. N+1 в get_orders() — 340 SQL-запросов на страницу списка
→ select_related('user', 'payment') + prefetch_related('items__product')
→ Ожидаемый эффект: 340 запросов → 4

3. Дублирование расчёта скидки — одна логика в 6 методах, каждый немного по-своему
→ DiscountCalculator с единым алгоритмом

4. Отсутствие транзакций — create_order() не обёрнут в transaction
→ Оплата прошла, но товар не зарезервирован (реальный баг, случается ~2 раза/мес)

5. Хардкод статусов — строки "pending", "paid", "shipped" в 23 местах
→ Django TextChoices enum

План на 2 недели:
Дни 1-3: Тесты на критические пути (create, cancel, refund)
Дни 4-6: Декомпозиция create_order() (п.1)
Дни 7-8: N+1 (п.2) + транзакции (п.4)
Дни 9-10: DiscountCalculator (п.3) + enum (п.5)

3 400 строк → ~1 200 строк в 8 файлах. Скорость разработки фич в orders — ×2.