Одноразовый прототип

Назначение

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

Также известен как

Throwaway prototype, spike (в терминах экстремального программирования), прототип-ответ; /prototype в скиллах Мэтта Покока.

Проблема

Некоторые решения трудно проверить одним обсуждением. Модель состояний может выглядеть полной, пока её не применили к последовательности реальных действий.

Например, отмена подписки и реактивация работают по отдельности, но при реактивации до отложенной отмены старое событие остаётся в очереди. Чтобы заметить ошибку, полезно выполнить переходы и увидеть состояние после каждого. Для интерфейса прототип позволяет попробовать разные способы выполнить одну задачу и сравнить их на практике.

Полная реализация ради такой проверки обходится дорого. Быстрый прототип сокращает затраты, если команда заранее отделяет эксперимент от кода, который будет сопровождать.

Решение

Сформулируйте вопрос и выберите минимальный эксперимент, способный дать ответ.

• Для модели состояний создайте небольшой инструмент с действиями и видимым состоянием. Терминал подходит разработчику; для обсуждения с экспертом удобно сделать отдельный HTML-файл с кнопками и сценариями.
• Для интерфейса подготовьте несколько вариантов с переключателем и сравните их на одном пользовательском сценарии.

Ограничьте объём экспериментального кода.

1. Явно пометьте прототип в имени и описании.
2. Обеспечьте запуск одной командой.
3. Храните состояние в памяти, если вопрос не требует проверки постоянного хранилища.
4. Добавляйте только код, необходимый для эксперимента.

Агент может быстро собрать такой инструмент, поэтому стоимость проверки решения снижается. Это особенно полезно, когда неверный выбор потребует переделки нескольких модулей.

Запишите вопрос, наблюдения и вывод в тикет или ADR. Сохраните прототип в отдельной ветке со ссылкой из решения. Рабочую реализацию создавайте по проверенным требованиям с обычными тестами и обработкой ошибок.

Структура

Вопрос определяет форму эксперимента. После прогона вывод и экспериментальный код сохраняются раздельно.

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

Участники / Компоненты

• Вопрос проектирования задаёт цель эксперимента.
• Прототип позволяет получить нужные наблюдения.
• Разработчик выполняет сценарии и принимает решение по результатам.
• Агент строит минимальный инструмент эксперимента.
• Вывод сохраняет проверенный вопрос, наблюдения и решение.

Когда применять

• Модель имеет последовательности состояний, которые трудно проверить рассуждением.
• Нужно сравнить варианты интерфейса на практике.
• Для труднообратимого решения не хватает наблюдений.

Сначала проверьте, можно ли получить ответ чтением кода или документации. Прототип нужен, когда более дешёвых сведений недостаточно.

Последствия и компромиссы

• ➕ Ошибка модели может обнаружиться до полной реализации.
• ➕ Участники обсуждают результаты одного эксперимента.
• ➕ Ограниченный объём снижает стоимость проверки идеи.
• ➖ Экспериментальный код легко принять за готовую основу продукта.
• ➖ Результат относится только к проверенному вопросу и условиям эксперимента.
• ➖ Прототип тратит время, если ответ уже доступен в документации.

Реализация

1. Запишите вопрос одним предложением.
2. Выберите терминальный сценарий, UI-макет или другую форму, которая даст нужные наблюдения.
3. Задайте имя, команду запуска и минимальные ограничения эксперимента.
4. Выполните трудные сценарии и сохраните наблюдения.
5. Запишите вывод и принятое решение в тикет или ADR.
6. Сохраните прототип в отдельной ветке, а рабочую реализацию создавайте по проверенному решению.
7. Для отдельной сессии прототипа подготовьте handoff с вопросом и контекстом.

Пример

В истории из главы о передаче сессии нужно проверить модель отмен для корпоративных контрактов с отложенным стартом. Вы передаёте новой сессии документ и задачу эксперимента.

Прочитай /tmp/handoff-cancellation-prototype.md и собери одноразовый прототип модели отмен

Первый сценарий проверяет исходный вопрос. Вы назначаете старт контракта на 1 октября, отмену на 25 сентября и переводите часы на 2 октября. В учебном эксперименте обработчик старта открывает доступ, хотя отмена уже вступила в силу. Такое наблюдение показывает, что одной очереди датированных событий недостаточно. При обработке старта нужно учитывать действующую отмену.

Второй сценарий проверяет реактивацию до отложенной отмены. Если в очереди остаётся прежнее событие отмены, оно позднее закроет восстановленную подписку. Команда фиксирует отдельное правило об аннулировании этого события при реактивации.

В ADR сохраняют оба наблюдения и решения с границами эксперимента. Прототип остаётся в prototype/cancellation-model, а тикет реализации получает ссылку на него. В рабочем коде оба сценария будут защищены тестами. Описанные наблюдения иллюстрируют возможные результаты прототипа; для своего проекта команда получает их реальным запуском.

Антипаттерны и частые ошибки

• «Допили этот прототип». Экспериментальный код может не иметь защиты, нужной рабочей системе. Реализуйте принятое решение с обычными проверками качества.
• Прототип без вопроса. Без критерия нельзя определить, какие наблюдения завершат эксперимент.
• Полировка одноразового. Лишние абстракции увеличивают стоимость получения ответа.
• Обобщение вывода. Успех сценария не подтверждает нагрузку и другие условия, которых эксперимент не касался.
• Потерянный вывод. Если удалить код без записи результата, вопрос придётся исследовать повторно.

Известные применения

• Скиллы Мэтта Покока реализуют эксперимент через /prototype. Для логики скилл создаёт отдельный HTML-файл со свободными действиями и пошаговыми сценариями; для UI переключаемые варианты. Проверенный прототип сохраняется в отдельной ветке со ссылкой из задачи.
• Spike solutions в экстремальном программировании снимают технический риск коротким экспериментом.
• «Спроектируй дважды» развивает принцип Джона Аустерхаута: сравнивать существенно разные варианты дизайна до реализации.
• Трассирующие пули из «Прагматичного программиста» дают код, который развивается дальше. Одноразовый прототип сохраняет только проверенное решение для новой реализации.

Связанные паттерны

• Спроектируй дважды сравнивает альтернативные конструкции; прототип проверяет вопросы, требующие наблюдений.
• Петля обратной связи связывает решение с наблюдаемым результатом проверки.
• Передача сессии сохраняет вопрос для отдельного эксперимента.
• Четыре фазы позволяет вынести неопределённость плана в прототип.
• Спеко-ориентированная разработка сохраняет вывод прототипа как требование или ограничение.
• Вайб-кодинг описывает принятие кода без сверки с требованиями. Так заканчивается прототип, который дописали до рабочей системы.