Files
claude-howto/uk/08-checkpoints/checkpoint-examples.md
Evgenij I b56f1e111a feat(uk): translate P3 examples for skills/refactor, subagents, checkpoints, advanced
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
2026-04-09 22:57:13 +03:00

343 lines
16 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Приклади контрольних точок
Реальні приклади ефективного використання контрольних точок у Claude Code.
Примітка: Контрольні точки створюються автоматично з кожним промптом користувача. Вам не потрібно зберігати їх вручну. Для відкату натисніть `Esc` двічі (`Esc+Esc`) або використовуйте `/rewind` для відкриття браузера контрольних точок.
## Приклад 1: Міграція бази даних
### Сценарій
Потрібно мігрувати з MySQL на PostgreSQL, але хочете дослідити як пряму міграцію, так і поступовий підхід з подвійним записом (dual-write).
### Робочий процес
```
Користувач: Реалізуймо пряму міграцію з MySQL на PostgreSQL
[Контрольна точка A створена автоматично]
Claude: Реалізую пряму міграцію...
[Змінює драйвер БД, оновлює запити, модифікує схему]
Користувач: Запусти тести
[Контрольна точка B створена автоматично]
Claude: Запускаю тести...
❌ 15 тестів не проходять — проблеми з пулом зʼєднань
Користувач: Цей підхід має проблеми. Спробуймо патерн dual-write.
[Користувач натискає Esc+Esc, обирає контрольну точку A, обирає "Restore code and conversation"]
Користувач: Тепер реалізуй патерн dual-write, де ми пишемо в обидві БД
Claude: Реалізую міграцію з dual-write...
[Реалізує рівень dual-write, стратегію поступової міграції]
Користувач: Запусти тести
Claude: Запускаю тести...
Усі тести проходять
Користувач: Підхід dual-write явно безпечніший. Закомітимо це.
```
## Приклад 2: Оптимізація продуктивності
### Сценарій
Кілька стратегій оптимізації продуктивності для випробування.
### Робочий процес
```
Користувач: Оптимізуймо час відповіді API. Поточний: 450мс
[Контрольна точка "Baseline" створена автоматично]
Claude: Додам кешування запитів до БД...
[Реалізує кешування Redis]
Користувач: Запусти тести продуктивності
Claude: Результати: 280мс середній час відповіді (покращення 38%)
Користувач: Спробую інший підхід.
[Користувач натискає Esc+Esc, обирає контрольну точку "Baseline", обирає "Restore code and conversation"]
Користувач: Спробуй оптимізацію запитів до БД
Claude: Оптимізую запити до БД...
[Додає індекси, оптимізує N+1 запити]
Користувач: Запусти тести продуктивності
Claude: Результати: 180мс середній час відповіді (покращення 60%)
Користувач: Спробую ще третій підхід.
[Користувач натискає Esc+Esc, обирає контрольну точку "Baseline", обирає "Restore code and conversation"]
Користувач: Спробуй стиснення відповідей та CDN
Claude: Додам стиснення та CDN...
[Реалізує gzip, налаштовує CDN]
Користувач: Запусти тести продуктивності
Claude: Результати: 320мс середній час відповіді (покращення 29%)
Користувач: Оптимізація запитів була найкращою. Повернуся та поєднаю з кешуванням.
[Користувач натискає Esc+Esc, обирає контрольну точку після оптимізації запитів, обирає "Restore code and conversation"]
Користувач: Тепер додай кешування Redis поверх цих оптимізованих запитів
Claude: [Додає кешування Redis поверх оптимізованих запитів]
Користувач: Запусти тести продуктивності
Claude: Результати: 95мс середній час відповіді (покращення 79%) 🎉
Користувач: Ідеально! Це переможець. Закомітимо.
```
## Приклад 3: Ітерація UI/UX
### Сценарій
Випробування різних макетів для дашборду.
### Робочий процес
```
Користувач: Перепроєктуймо дашборд з бічною панеллю
[Контрольна точка "Start" створена автоматично]
Claude: [Реалізує макет з бічною панеллю]
Користувач: Покажи скріншот
Claude: [Показує скріншот]
Користувач: Бічна панель тісна. Спробуймо верхню навігацію.
[Користувач натискає Esc+Esc, обирає контрольну точку "Start", обирає "Restore code and conversation"]
Користувач: Спробуй макет з верхньою навігацією
Claude: [Реалізує верхню навігацію]
Користувач: Покажи скріншот
Claude: [Показує скріншот]
Користувач: Краще, але спробуймо макет у вигляді сітки карток
[Користувач натискає Esc+Esc, обирає контрольну точку "Start", обирає "Restore code and conversation"]
Користувач: Спробуй макет сітки карток
Claude: [Реалізує сітку карток]
Користувач: Покажи скріншот
Claude: [Показує скріншот]
Користувач: Чудово! Але чи можемо поєднати верхню навігацію із сіткою карток?
[Користувач натискає Esc+Esc, обирає контрольну точку після сітки карток, обирає "Restore code and conversation"]
Користувач: Додай верхню навігацію до макету сітки карток
Claude: [Додає верхню навігацію до сітки карток]
Користувач: Ідеально! Це фінальний дизайн.
```
## Приклад 4: Сесія налагодження
### Сценарій
Полювання на складну помилку з кількома гіпотезами.
### Робочий процес
```
Користувач: В додатку є витік памʼяті
[Контрольна точка "Before debugging" створена автоматично]
Claude: Досліджую...
[Аналізує код]
Користувач: Думаю, це в обробниках подій. Виправимо їх.
Claude: [Виправляє очищення обробників подій]
Користувач: Запусти профілювальник памʼяті
Claude: Памʼять все ще тече — обробники подій не були причиною
Користувач: Повернуся та спробую іншу гіпотезу.
[Користувач натискає Esc+Esc, обирає контрольну точку "Before debugging", обирає "Restore code and conversation"]
Користувач: Може це зʼєднання з БД?
Claude: [Реалізує виправлення пулу зʼєднань]
Користувач: Запусти профілювальник памʼяті
Claude: Все ще тече — не зʼєднання
Користувач: Повернуся та спробую інший ракурс.
[Користувач натискає Esc+Esc, обирає контрольну точку "Before debugging", обирає "Restore code and conversation"]
Користувач: Перевіримо циклічні посилання
Claude: [Знаходить та виправляє циклічні посилання в кеші]
Користувач: Запусти профілювальник памʼяті
Claude: ✅ Витік памʼяті виправлено! Циклічні посилання в рівні кешування були причиною.
Користувач: Відмінно! Закомітимо це виправлення.
```
## Приклад 5: Еволюція дизайну API
### Сценарій
Проєктування REST API з кількома ітераціями.
### Робочий процес
```
Користувач: Створи REST API для нашої блог-платформи
[Контрольна точка "Before API design" створена автоматично]
Claude: [Створює базовий CRUD API]
Користувач: Це занадто просто. Додаймо пагінацію та фільтрацію
Claude: [Додає пагінацію та фільтрацію]
Користувач: Потрібні кращі звʼязки між ресурсами
Claude: [Реалізує HATEOAS-посилання]
Користувач: Власне, спробуймо GraphQL замість REST
[Користувач натискає Esc+Esc, обирає контрольну точку "Before API design", обирає "Restore code and conversation"]
Користувач: Реалізуй GraphQL API для нашої блог-платформи
Claude: [Реалізує GraphQL API]
Користувач: Думаю, REST краще для нашого випадку.
[Користувач натискає Esc+Esc, обирає контрольну точку після HATEOAS, обирає "Restore code and conversation"]
Користувач: Фіналізуємо REST-підхід.
```
## Приклад 6: Управління конфігурацією
### Сценарій
Тестування різних підходів до конфігурації.
### Робочий процес
```
Користувач: Перемісти конфігурацію у змінні оточення
[Контрольна точка "Original config" створена автоматично]
Claude: [Реалізує конфігурацію через змінні оточення]
Користувач: Тест у середовищі розробки
Claude: Працює локально, але проблеми з деплоєм на продакшні
Користувач: Спробую інший підхід.
[Користувач натискає Esc+Esc, обирає контрольну точку "Original config", обирає "Restore code and conversation"]
Користувач: Спробуй підхід з файлом конфігурації та валідацією
Claude: [Реалізує YAML-конфігурацію з валідацією JSON Schema]
Користувач: Тест у середовищі розробки
Claude: ✅ Працює добре, хороші повідомлення про помилки валідації
Користувач: Чи можемо також підтримувати змінні оточення для чутливих значень?
Claude: [Додає перевизначення через змінні оточення для секретів]
Користувач: Тест деплою
Claude: ✅ Усі середовища працюють коректно
Користувач: Ідеально! Це готове для продакшну.
```
## Приклад 7: Стратегія тестування
### Сценарій
Реалізація комплексного тестування.
### Робочий процес
```
Користувач: Додай юніт-тести для модуля автентифікації
[Контрольна точка створена автоматично]
Claude: [Додає юніт-тести Jest]
Користувач: Запусти тести
Claude: 45 тестів проходять, 78% покриття
Користувач: Додай також інтеграційні тести
Claude: [Додає інтеграційні тести]
Користувач: Запусти тести
Claude: 89 тестів проходять, 92% покриття, але тести повільні (3 хвилини)
Користувач: Тести занадто повільні. Оптимізуймо.
Claude: [Оптимізує налаштування тестів, додає паралельне виконання]
Користувач: Запусти тести
Claude: 89 тестів проходять, 92% покриття, 35 секунд ✅
Користувач: Чудово! Тепер додай E2E тести для критичних шляхів
Claude: [Додає E2E тести Playwright]
Користувач: Запусти всі тести
Claude: 112 тестів проходять, 94% покриття, 2 хвилини
Користувач: Ідеальний баланс покриття та швидкості!
```
## Приклад 8: Використання підсумку від контрольної точки
### Сценарій
Після довгої сесії налагодження хочете стиснути розмову, зберігаючи контекст.
### Робочий процес
```
Користувач: [Після 20+ повідомлень налагодження та дослідження]
[Користувач натискає Esc+Esc, обирає ранню контрольну точку, обирає "Summarize from here"]
[Необовʼязково надає інструкції: "Зосередься на тому, що ми спробували і що спрацювало"]
Claude: [Генерує підсумок розмови від цієї точки далі]
[Оригінальні повідомлення зберігаються в транскрипті]
[Підсумок замінює видиму розмову, зменшуючи використання контекстного вікна]
Користувач: Тепер продовжимо з підходом, що спрацював.
```
## Ключові висновки
1. **Контрольні точки автоматичні**: Кожен промпт користувача створює контрольну точку — ручне збереження не потрібне
2. **Використовуйте Esc+Esc або /rewind**: Два способи доступу до браузера контрольних точок
3. **Обирайте правильний варіант відновлення**: Відновити код, розмову, обидва або підсумувати — залежно від потреб
4. **Не бійтеся експериментувати**: Контрольні точки роблять безпечним випробування радикальних змін
5. **Поєднуйте з git**: Контрольні точки для дослідження, git для фіналізованої роботи
6. **Підсумовуйте довгі сесії**: Використовуйте "Summarize from here" для підтримки керованості розмов
---
**Останнє оновлення**: 9 квітня 2026