03-skills/refactor: SKILL.md + templates/refactoring-plan.md 04-subagents: 8 agent definitions 08-checkpoints: checkpoint-examples.md 09-advanced: planning-mode-examples.md Remaining: refactor references (1692 lines), P4 root docs Ref: luongnv89/claude-howto#63
494 lines
25 KiB
Markdown
494 lines
25 KiB
Markdown
# Приклади режиму планування
|
||
|
||
Реальні приклади ефективного використання режиму планування в Claude Code.
|
||
|
||
## Приклад 1: Створення REST API
|
||
|
||
### Без режиму планування
|
||
|
||
```
|
||
Користувач: Створи REST API для блогу
|
||
|
||
Claude: Створю API...
|
||
[Одразу починає кодувати, може пропустити вимоги]
|
||
```
|
||
|
||
### З режимом планування
|
||
|
||
```
|
||
Користувач: /plan Створи REST API для блогу
|
||
|
||
Claude: Створю комплексний план для API блогу.
|
||
|
||
## План реалізації REST API блогу
|
||
|
||
### Фаза 1: Налаштування проєкту (15 хв)
|
||
1. Ініціалізувати проєкт Node.js з Express
|
||
2. Налаштувати конфігурацію TypeScript
|
||
3. Встановити залежності (express, pg, jwt, joi)
|
||
4. Налаштувати змінні оточення
|
||
5. Встановити структуру проєкту
|
||
|
||
### Фаза 2: Рівень бази даних (30 хв)
|
||
6. Спроєктувати схему БД
|
||
- таблиця users (id, email, password_hash, created_at)
|
||
- таблиця posts (id, user_id, title, content, published, created_at, updated_at)
|
||
- таблиця comments (id, post_id, user_id, content, created_at)
|
||
7. Створити файли міграцій
|
||
8. Налаштувати пул зʼєднань з БД
|
||
9. Реалізувати моделі БД
|
||
|
||
### Фаза 3: Автентифікація (45 хв)
|
||
10. Реалізувати ендпоінт реєстрації
|
||
11. Реалізувати ендпоінт входу з JWT
|
||
12. Створити middleware автентифікації
|
||
13. Додати хешування паролів з bcrypt
|
||
14. Реалізувати логіку оновлення токенів
|
||
|
||
### Фаза 4: API постів (40 хв)
|
||
15. GET /api/posts — список усіх опублікованих постів (з пагінацією)
|
||
16. GET /api/posts/:id — отримати окремий пост
|
||
17. POST /api/posts — створити новий пост (потрібна автентифікація)
|
||
18. PUT /api/posts/:id — оновити пост (автентифікація, перевірка власності)
|
||
19. DELETE /api/posts/:id — видалити пост (автентифікація, перевірка власності)
|
||
20. GET /api/users/:id/posts — отримати пости користувача
|
||
|
||
### Фаза 5: API коментарів (30 хв)
|
||
21. GET /api/posts/:id/comments — отримати коментарі посту
|
||
22. POST /api/posts/:id/comments — додати коментар (потрібна автентифікація)
|
||
23. DELETE /api/comments/:id — видалити коментар (автентифікація, перевірка власності)
|
||
|
||
### Фаза 6: Валідація та обробка помилок (30 хв)
|
||
24. Додати валідацію запитів з Joi
|
||
25. Реалізувати глобальний обробник помилок
|
||
26. Додати санітизацію вхідних даних
|
||
27. Реалізувати обмеження частоти запитів
|
||
|
||
### Фаза 7: Тестування (60 хв)
|
||
28. Написати юніт-тести для моделей
|
||
29. Написати інтеграційні тести для ендпоінтів автентифікації
|
||
30. Написати інтеграційні тести для ендпоінтів постів
|
||
31. Написати інтеграційні тести для ендпоінтів коментарів
|
||
32. Досягти 80%+ покриття коду
|
||
|
||
### Фаза 8: Документація та деплой (30 хв)
|
||
33. Згенерувати API-документацію зі Swagger
|
||
34. Створити README з інструкціями налаштування
|
||
35. Додати конфігурацію Docker
|
||
36. Налаштувати CI/CD пайплайн
|
||
|
||
**Орієнтовний час**: 4.5 години
|
||
**Файлів для створення**: ~25
|
||
**Ключові технології**: Express, PostgreSQL, JWT, TypeScript
|
||
|
||
**Резюме API-ендпоінтів**:
|
||
- Автентифікація: 2 ендпоінти
|
||
- Пости: 6 ендпоінтів
|
||
- Коментарі: 3 ендпоінти
|
||
- Загалом: 11 ендпоінтів
|
||
|
||
Готові продовжити? (yes/no/modify)
|
||
|
||
Користувач: yes
|
||
|
||
Claude: Починаю Фазу 1: Налаштування проєкту...
|
||
[Реалізує кожну фазу систематично]
|
||
```
|
||
|
||
## Приклад 2: Міграція бази даних
|
||
|
||
### З режимом планування
|
||
|
||
```
|
||
Користувач: /plan Мігрувати з MongoDB на PostgreSQL
|
||
|
||
Claude: Це складна міграція. Створю детальний план.
|
||
|
||
## План міграції MongoDB → PostgreSQL
|
||
|
||
### Фаза 1: Аналіз та підготовка (День 1)
|
||
1. Проаналізувати поточну схему MongoDB
|
||
2. Визначити звʼязки та обмеження даних
|
||
3. Задокументувати поточний обсяг та темп зростання даних
|
||
4. Спроєктувати еквівалентну схему PostgreSQL
|
||
5. Спланувати відповідності типів даних
|
||
6. Визначити потенційні складнощі міграції
|
||
|
||
### Фаза 2: Налаштування PostgreSQL (День 1)
|
||
7. Налаштувати БД PostgreSQL
|
||
8. Створити схему з таблицями, індексами, обмеженнями
|
||
9. Налаштувати пул зʼєднань
|
||
10. Налаштувати стратегію резервного копіювання
|
||
|
||
### Фаза 3: Реалізація dual-write (Дні 2-3)
|
||
11. Створити рівень абстракції БД
|
||
12. Реалізувати dual-write в обидві БД
|
||
13. Додати перевірки консистентності даних
|
||
14. Деплой dual-write на staging
|
||
15. Моніторинг на предмет проблем
|
||
|
||
### Фаза 4: Міграція даних (День 4)
|
||
16. Створити скрипти експорту даних з MongoDB
|
||
17. Створити скрипти імпорту даних у PostgreSQL
|
||
18. Реалізувати логіку трансформації даних
|
||
19. Запустити початкову міграцію на копії продакшн-даних
|
||
20. Валідувати цілісність мігрованих даних
|
||
|
||
### Фаза 5: Поступове переключення (Дні 5-7)
|
||
21. Увімкнути dual-write на продакшні
|
||
22. Мігрувати історичні дані пакетами
|
||
23. Безперервно валідувати консистентність даних
|
||
24. Моніторити обидві БД
|
||
25. Виправляти проблеми синхронізації даних
|
||
|
||
### Фаза 6: PostgreSQL як основна (День 8)
|
||
26. Переключити операції читання на PostgreSQL
|
||
27. Моніторити продуктивність запитів
|
||
28. Оптимізувати повільні запити
|
||
29. Продовжити dual-write для безпеки
|
||
|
||
### Фаза 7: Виведення MongoDB (Дні 9-10)
|
||
30. Припинити запис у MongoDB
|
||
31. Залишити MongoDB як бекап на 2 тижні
|
||
32. Видалити залежності від MongoDB з коду
|
||
33. Архівувати дані MongoDB
|
||
34. Вивести з експлуатації інстанс MongoDB
|
||
|
||
**Орієнтовний час**: 10 днів
|
||
**Рівень ризику**: Високий
|
||
**Стратегія відкату**: Залишити MongoDB запущеною з dual-write
|
||
**Критерії успіху**:
|
||
- Нуль втрат даних
|
||
- <5% регресії продуктивності
|
||
- Усі тести проходять
|
||
|
||
Продовжити з цим планом? (yes/no/modify)
|
||
|
||
Користувач: Modify — додаймо план відкату для кожної фази
|
||
|
||
Claude: Оновлений план з процедурами відкату для кожної фази...
|
||
```
|
||
|
||
## Приклад 3: Рефакторинг фронтенду
|
||
|
||
```
|
||
Користувач: /plan Рефакторити React-додаток з класових компонентів на хуки
|
||
|
||
Claude: Створю систематичний план рефакторингу.
|
||
|
||
## План міграції React Class → Hooks
|
||
|
||
### Фаза 1: Підготовка та аналіз (2 години)
|
||
1. Аудит усіх класових компонентів
|
||
2. Категоризація за складністю:
|
||
- Прості (лише стан): ~15 компонентів
|
||
- Середні (методи життєвого циклу): ~23 компоненти
|
||
- Складні (кілька lifecycle, refs): ~8 компонентів
|
||
3. Визначити бібліотеки, що потребують оновлення
|
||
4. Створити граф залежностей компонентів
|
||
5. Спланувати порядок міграції (листові вузли першими)
|
||
|
||
### Фаза 2: Налаштування та інструменти (1 година)
|
||
6. Оновити React до v18+
|
||
7. Налаштувати правила ESLint для хуків
|
||
8. Створити шаблони конверсії
|
||
9. Налаштувати автоматичні тести
|
||
10. Створити контрольну точку перед початком
|
||
|
||
### Фаза 3: Міграція простих компонентів (4 години)
|
||
11. Конвертувати прості stateful компоненти (15 компонентів)
|
||
12. Замінити this.state на useState
|
||
13. Замінити this.setState на сетери стану
|
||
14. Тестувати кожен компонент після конверсії
|
||
15. Оновити тести
|
||
|
||
### Фаза 4: Міграція середніх компонентів (8 годин)
|
||
16. Конвертувати компоненти з методами lifecycle (23 компоненти)
|
||
17. Замінити componentDidMount на useEffect
|
||
18. Замінити componentDidUpdate на useEffect
|
||
19. Замінити componentWillUnmount на очищення useEffect
|
||
20. Ретельно тестувати
|
||
|
||
### Фаза 5: Міграція складних компонентів (12 годин)
|
||
21. Конвертувати складні компоненти (8 компонентів)
|
||
22. Замінити refs на useRef
|
||
23. Витягти кастомні хуки для спільної логіки
|
||
24. Обробити крайні випадки (кілька useEffect)
|
||
25. Розширене тестування
|
||
|
||
### Фаза 6: Витяг спільної логіки (6 годин)
|
||
26. Виявити дубльовану логіку між компонентами
|
||
27. Створити кастомні хуки:
|
||
- useAuth
|
||
- useFetch
|
||
- useLocalStorage
|
||
- useDebounce
|
||
28. Рефакторити компоненти для використання кастомних хуків
|
||
29. Тестувати кастомні хуки незалежно
|
||
|
||
### Фаза 7: Оптимізація продуктивності (4 години)
|
||
30. Додати React.memo де потрібно
|
||
31. Оптимізувати з useCallback
|
||
32. Оптимізувати з useMemo
|
||
33. Профілювати та виправити регресії продуктивності
|
||
|
||
### Фаза 8: Очищення та документація (2 години)
|
||
34. Видалити невикористані утиліти класових компонентів
|
||
35. Оновити документацію
|
||
36. Оновити рекомендації з кодування
|
||
37. Створити посібник міграції для команди
|
||
|
||
**Орієнтовний час**: 5 днів (39 годин)
|
||
**Файлів для зміни**: 46 компонентів
|
||
**Рівень ризику**: Середній
|
||
|
||
**Порядок міграції**:
|
||
1. Листові компоненти (без залежностей)
|
||
2. Компоненти середнього рівня
|
||
3. Контейнерні компоненти верхнього рівня
|
||
4. App.jsx (останній)
|
||
|
||
Продовжити? (yes/no/modify)
|
||
```
|
||
|
||
## Приклад 4: Реалізація безпеки
|
||
|
||
```
|
||
Користувач: /plan Реалізувати комплексну безпеку для нашого веб-додатку
|
||
|
||
Claude: Створю ретельний план реалізації безпеки.
|
||
|
||
## План реалізації безпеки веб-додатку
|
||
|
||
### Фаза 1: Аудит безпеки (День 1)
|
||
1. Запустити автоматичні сканери безпеки (npm audit, Snyk)
|
||
2. Перевірити залежності на вразливості
|
||
3. Перевірити відповідність OWASP Top 10
|
||
4. Аудит потоків автентифікації
|
||
5. Перевірити практики обробки даних
|
||
6. Задокументувати поточні прогалини безпеки
|
||
|
||
### Фаза 2: Посилення автентифікації (Дні 2-3)
|
||
7. Реалізувати вимоги до складності паролів
|
||
8. Додати індикатор надійності пароля
|
||
9. Реалізувати обмеження частоти спроб входу
|
||
10. Додати блокування облікового запису після невдалих спроб
|
||
11. Реалізувати 2FA (TOTP)
|
||
12. Покращити управління сесіями
|
||
13. Реалізувати безпечний потік скидання пароля
|
||
|
||
### Фаза 3: Авторизація та контроль доступу (Дні 3-4)
|
||
14. Реалізувати RBAC (контроль доступу на основі ролей)
|
||
15. Додати перевірки дозволів на всіх ендпоінтах
|
||
16. Реалізувати принцип мінімальних привілеїв
|
||
17. Додати журнал аудиту для чутливих операцій
|
||
18. Реалізувати дозволи на рівні ресурсів
|
||
|
||
### Фаза 4: Захист даних (Дні 4-5)
|
||
19. Реалізувати шифрування в стані спокою (чутливі поля)
|
||
20. Забезпечити TLS/SSL для всіх комунікацій
|
||
21. Реалізувати безпечне зберігання сесій
|
||
22. Додати маскування PII у журналах
|
||
23. Реалізувати політики збереження даних
|
||
24. Додати безпечну обробку завантаження файлів
|
||
|
||
### Фаза 5: Валідація та санітизація введення (Дні 5-6)
|
||
25. Реалізувати валідацію введення на всіх ендпоінтах
|
||
26. Додати захист від XSS (Content Security Policy)
|
||
27. Реалізувати захист від SQL-інʼєкцій (параметризовані запити)
|
||
28. Додати захист від CSRF
|
||
29. Реалізувати ліміти розміру запитів
|
||
30. Додати валідацію типів файлів при завантаженні
|
||
|
||
### Фаза 6: Заголовки безпеки та конфігурація (День 6)
|
||
31. Додати заголовки безпеки:
|
||
- Strict-Transport-Security
|
||
- X-Content-Type-Options
|
||
- X-Frame-Options
|
||
- X-XSS-Protection
|
||
- Content-Security-Policy
|
||
32. Правильно налаштувати CORS
|
||
33. Вимкнути непотрібні HTTP-методи
|
||
34. Видалити заголовки версії сервера
|
||
|
||
### Фаза 7: Моніторинг та логування (День 7)
|
||
35. Реалізувати логування подій безпеки
|
||
36. Додати виявлення аномалій
|
||
37. Налаштувати виявлення вторгнень
|
||
38. Реалізувати алертинг у реальному часі
|
||
39. Створити дашборд безпеки
|
||
|
||
### Фаза 8: Тестування та документація (Дні 8-9)
|
||
40. Провести тестування на проникнення
|
||
41. Запустити сканери безпеки
|
||
42. Протестувати всі функції безпеки
|
||
43. Створити документацію безпеки
|
||
44. Навчити команду практикам безпеки
|
||
45. Створити план реагування на інциденти
|
||
|
||
### Фаза 9: Відповідність та політики (День 10)
|
||
46. Перевірка відповідності GDPR
|
||
47. Створити політику конфіденційності
|
||
48. Реалізувати права субʼєктів даних
|
||
49. Додати згоду на cookies
|
||
50. Створити документацію політик безпеки
|
||
|
||
**Орієнтовний час**: 10 днів
|
||
**Рівень ризику**: Критичний
|
||
**Пріоритет**: Високий
|
||
|
||
**Відповідність**: OWASP Top 10, GDPR
|
||
|
||
Продовжити? (yes/no/modify)
|
||
```
|
||
|
||
## Приклад 5: Оптимізація продуктивності
|
||
|
||
```
|
||
Користувач: /plan Оптимізувати наш повільний сайт електронної комерції
|
||
|
||
Claude: Створю комплексний план оптимізації продуктивності.
|
||
|
||
## План оптимізації продуктивності електронної комерції
|
||
|
||
### Фаза 1: Аудит продуктивності (4 години)
|
||
1. Запустити аудит Lighthouse
|
||
2. Проаналізувати профіль продуктивності Chrome DevTools
|
||
3. Виміряти Core Web Vitals:
|
||
- LCP (Largest Contentful Paint)
|
||
- FID (First Input Delay)
|
||
- CLS (Cumulative Layout Shift)
|
||
4. Визначити вузькі місця продуктивності
|
||
5. Створити базові метрики продуктивності
|
||
|
||
**Поточні метрики**:
|
||
- LCP: 4.2с (ціль: <2.5с)
|
||
- FID: 280мс (ціль: <100мс)
|
||
- CLS: 0.25 (ціль: <0.1)
|
||
- Завантаження сторінки: 8.3с (ціль: <3с)
|
||
|
||
### Фаза 2: Оптимізація зображень (6 годин)
|
||
6. Конвертувати зображення у формат WebP
|
||
7. Реалізувати адаптивні зображення
|
||
8. Додати ліниве завантаження зображень
|
||
9. Оптимізувати розміри зображень (стиснення)
|
||
10. Реалізувати CDN для зображень
|
||
11. Додати плейсхолдери зображень
|
||
|
||
**Очікуваний вплив**: -40% час завантаження
|
||
|
||
### Фаза 3: Розділення коду та ліниве завантаження (8 годин)
|
||
12. Реалізувати розділення коду за маршрутами
|
||
13. Ліниво завантажувати некритичні компоненти
|
||
14. Розділити vendor-бандли
|
||
15. Оптимізувати розміри чанків
|
||
16. Реалізувати динамічні імпорти
|
||
17. Додати попереднє завантаження критичних ресурсів
|
||
|
||
**Очікуваний вплив**: -30% початковий розмір бандлу
|
||
|
||
### Фаза 4: Стратегія кешування (6 годин)
|
||
18. Реалізувати кешування браузером (Cache-Control)
|
||
19. Додати service worker для офлайн-підтримки
|
||
20. Реалізувати кешування відповідей API
|
||
21. Додати кеш Redis для запитів до БД
|
||
22. Реалізувати stale-while-revalidate
|
||
23. Налаштувати кешування CDN
|
||
|
||
**Очікуваний вплив**: -50% час відповіді API
|
||
|
||
### Фаза 5: Оптимізація БД (8 годин)
|
||
24. Додати індекси в БД
|
||
25. Оптимізувати повільні запити (>100мс)
|
||
26. Реалізувати кешування результатів запитів
|
||
27. Додати пул зʼєднань
|
||
28. Денормалізувати де доречно
|
||
29. Реалізувати репліки БД для читання
|
||
|
||
**Очікуваний вплив**: -60% час запитів до БД
|
||
|
||
### Фаза 6: Оптимізація фронтенду (10 годин)
|
||
30. Мінімізувати та стиснути JavaScript
|
||
31. Мінімізувати та стиснути CSS
|
||
32. Видалити невикористаний CSS (PurgeCSS)
|
||
33. Реалізувати критичний CSS
|
||
34. Відкласти некритичний JavaScript
|
||
35. Зменшити розмір DOM
|
||
36. Оптимізувати рендеринг React (memo, useMemo)
|
||
37. Реалізувати віртуальний скролінг для довгих списків
|
||
|
||
**Очікуваний вплив**: -35% час виконання JavaScript
|
||
|
||
### Фаза 7: Оптимізація мережі (4 години)
|
||
38. Увімкнути HTTP/2
|
||
39. Реалізувати підказки ресурсів (preconnect, prefetch)
|
||
40. Зменшити кількість HTTP-запитів
|
||
41. Увімкнути стиснення Brotli
|
||
42. Оптимізувати сторонні скрипти
|
||
|
||
**Очікуваний вплив**: -25% мережевий час
|
||
|
||
### Фаза 8: Моніторинг та тестування (4 години)
|
||
43. Налаштувати моніторинг продуктивності (Datadog/New Relic)
|
||
44. Додати Real User Monitoring (RUM)
|
||
45. Створити бюджети продуктивності
|
||
46. Налаштувати автоматичний Lighthouse CI
|
||
47. Тестувати на реальних пристроях
|
||
|
||
**Орієнтовний час**: 50 годин (2 тижні)
|
||
|
||
**Цільові метрики** (90-й перцентиль):
|
||
- LCP: <2.0с (з 4.2с) ✅
|
||
- FID: <50мс (з 280мс) ✅
|
||
- CLS: <0.05 (з 0.25) ✅
|
||
- Завантаження: <2.5с (з 8.3с) ✅
|
||
|
||
**Порядок пріоритету**:
|
||
1. Оптимізація зображень (швидкі перемоги)
|
||
2. Розділення коду (високий вплив)
|
||
3. Кешування (високий вплив)
|
||
4. Оптимізація БД (критично)
|
||
5. Оптимізація фронтенду (полірування)
|
||
|
||
Продовжити з цим планом? (yes/no/modify)
|
||
```
|
||
|
||
## Ключові висновки
|
||
|
||
### Переваги режиму планування
|
||
|
||
1. **Ясність**: Чіткий план дій перед початком
|
||
2. **Оцінка**: Оцінки часу та зусиль
|
||
3. **Оцінка ризиків**: Раннє виявлення потенційних проблем
|
||
4. **Пріоритезація**: Логічний порядок завдань
|
||
5. **Затвердження**: Перегляд та затвердження перед виконанням
|
||
6. **Модифікація**: Коригування плану на основі зворотного звʼязку
|
||
|
||
### Коли використовувати режим планування
|
||
|
||
✅ **Завжди використовуйте для**:
|
||
- Багатоденних проєктів
|
||
- Командних співпраць
|
||
- Критичних змін системи
|
||
- Вивчення нових концепцій
|
||
- Складного рефакторингу
|
||
|
||
❌ **Не використовуйте для**:
|
||
- Виправлення помилок
|
||
- Дрібних правок
|
||
- Простих запитань
|
||
- Швидких експериментів
|
||
|
||
### Найкращі практики
|
||
|
||
1. **Ретельно переглядайте плани** перед затвердженням
|
||
2. **Модифікуйте плани**, коли помічаєте проблеми
|
||
3. **Розбивайте** складні завдання
|
||
4. **Оцінюйте реалістичні** часові рамки
|
||
5. **Включайте стратегії відкату**
|
||
6. **Додавайте критерії успіху**
|
||
7. **Плануйте тестування** на кожній фазі
|
||
|
||
---
|
||
**Останнє оновлення**: 9 квітня 2026
|