Files
sfera/improvement-plan.md
Veronika Smirnova 94ea6c2c77 feat(supplies): remove old monolithic create-suppliers-supply-page.tsx
Завершение ФАЗЫ 1 миграции:
- Удален старый файл create-suppliers-supply-page.tsx (1,467 строк)
- Новая модульная архитектура полностью функциональна
- Страница загружается быстрее (44ms vs 2.1s компиляции)
- Никаких импортов старого файла не обнаружено

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-12 20:35:33 +03:00

7.6 KiB
Raw Blame History

📋 БЕЗОПАСНЫЙ ПОЭТАПНЫЙ ПЛАН УЛУЧШЕНИЙ

🎯 ЦЕЛЬ

Безопасная оптимизация и улучшение новой модульной архитектуры компонента создания поставок

📅 ФАЗЫ РЕАЛИЗАЦИИ

ФАЗА 1: ЗАВЕРШЕНИЕ МИГРАЦИИ (1-2 часа)

Приоритет: КРИТИЧЕСКИЙ Риск: НИЗКИЙ

1.1 Тестирование новой архитектуры (30 мин)

  • Запустить приложение и протестировать функционал создания поставки
  • Проверить все 4 блока на корректность работы
  • Убедиться в правильности передачи данных между компонентами
  • Проверить обработку ошибок и граничных случаев

1.2 Удаление старого файла (10 мин)

  • После успешного тестирования удалить create-suppliers-supply-page.tsx
  • Обновить все импорты (если есть)
  • Сделать отдельный коммит для возможности отката

ФАЗА 2: ОПТИМИЗАЦИЯ ПРОИЗВОДИТЕЛЬНОСТИ (2-3 часа)

Приоритет: ВЫСОКИЙ Риск: НИЗКИЙ

2.1 Мемоизация блок-компонентов (1 час)

// Обернуть каждый блок в React.memo
export const SuppliersBlock = React.memo(({ ... }) => { ... })
export const ProductCardsBlock = React.memo(({ ... }) => { ... })
export const DetailedCatalogBlock = React.memo(({ ... }) => { ... })
export const CartBlock = React.memo(({ ... }) => { ... })

2.2 Оптимизация хуков (1 час)

  • Добавить useMemo для тяжелых вычислений
  • Использовать useCallback для обработчиков событий
  • Проверить и устранить лишние ререндеры

2.3 Lazy loading для больших списков (30 мин)

  • Реализовать виртуализацию для списка товаров
  • Добавить пагинацию или бесконечный скролл

ФАЗА 3: ТЕСТИРОВАНИЕ (3-4 часа)

Приоритет: ВЫСОКИЙ Риск: НИЗКИЙ

3.1 Unit тесты для хуков (2 часа)

// Пример структуры теста
describe('useSupplierSelection', () => {
  it('should filter suppliers by search query', () => { ... })
  it('should handle supplier selection', () => { ... })
  it('should handle loading states', () => { ... })
})

3.2 Integration тесты для блоков (1.5 часа)

  • Тестировать взаимодействие между блоками
  • Проверить корректность отображения данных
  • Тестировать обработку пользовательских действий

ФАЗА 4: ПРИМЕНЕНИЕ ПАТТЕРНА К ДРУГИМ КОМПОНЕНТАМ (8-12 часов)

Приоритет: СРЕДНИЙ Риск: СРЕДНИЙ

4.1 Анализ и приоритизация (1 час)

  • Оценить сложность рефакторинга каждого большого компонента
  • Определить порядок миграции по важности и сложности

4.2 Миграция add-goods-modal.tsx (3-4 часа)

  • Создать types/add-goods.types.ts
  • Выделить хуки для управления состоянием
  • Создать блок-компоненты для UI частей
  • Интегрировать и протестировать

4.3 Миграция fulfillment-supplies-page.tsx (2-3 часа)

  • Применить аналогичный подход
  • Переиспользовать общие компоненты где возможно

4.4 Миграция create-fulfillment-consumables-supply-page.tsx (2-3 часа)

  • Завершить миграцию больших компонентов

ФАЗА 5: СОЗДАНИЕ ПЕРЕИСПОЛЬЗУЕМЫХ КОМПОНЕНТОВ (4-6 часов)

Приоритет: СРЕДНИЙ Риск: НИЗКИЙ

5.1 Выделение общих паттернов (2 часа)

  • Идентифицировать повторяющиеся UI элементы
  • Создать shared компоненты для:
    • Выбора организации (OrganizationSelector)
    • Карточки товара (ProductCard)
    • Управления количеством (QuantityControl)

5.2 Создание UI Kit компонентов (3 часа)

  • Разработать компоненты согласно дизайн-системе
  • Добавить в glass-morphism коллекцию
  • Документировать API компонентов

ФАЗА 6: ДОКУМЕНТАЦИЯ (2-3 часа)

Приоритет: НИЗКИЙ Риск: МИНИМАЛЬНЫЙ

6.1 Техническая документация (1 час)

  • Создать README для папки create-suppliers
  • Документировать архитектуру и flow данных
  • Добавить примеры использования хуков

6.2 Storybook stories (2 часа)

  • Создать stories для каждого блок-компонента
  • Добавить различные состояния и варианты
  • Интегрировать с существующим Storybook

⚠️ ПРАВИЛА БЕЗОПАСНОСТИ

  1. Каждая фаза - отдельная ветка

    • Создавать feature ветку для каждой фазы
    • Мержить только после полного тестирования
  2. Инкрементальные изменения

    • Коммитить после каждого успешного шага
    • Не делать больших изменений за раз
  3. Откат всегда возможен

    • Сохранять старые версии до подтверждения работы новых
    • Использовать feature flags при необходимости
  4. Тестирование на каждом шаге

    • Запускать lint и тесты после каждого изменения
    • Проверять функционал в браузере

📊 МЕТРИКИ УСПЕХА

  • Уменьшение размера файлов на 30-50%
  • Улучшение производительности рендеринга
  • Повышение переиспользуемости кода
  • 80%+ покрытие тестами для критической логики
  • Снижение времени на добавление новых фич

🚀 ПОРЯДОК ВЫПОЛНЕНИЯ

  1. Сначала - Фаза 1 (критически важно)
  2. Затем - Фаза 2 и 3 параллельно
  3. После - Фаза 4 (постепенно)
  4. В конце - Фаза 5 и 6

Этот план обеспечивает безопасную и постепенную эволюцию кодовой базы с минимальными рисками и максимальной отдачей.