Разработка на основе спецификации.
Сначала напишите явную, авторитетную спецификацию, а затем выводите из неё реализацию, тесты и генерируемый код — сохраняя спецификацию как единственный источник истины.
##Intent
Сделайте точную спецификацию основным артефактом разработки. Реализация, тесты и даже сгенерированный ИИ код выводятся из спецификации и проверяются по ней, вместо того чтобы спецификация была одноразовым документом, написанным перед «настоящей» работой.
##Problem
Требования обычно живут в головах людей, в чатах или в устаревших документах. Реализация отходит от намерения, и когда это происходит, нет авторитетного источника, чтобы рассудить, что система должна делать.
Сильнее всего это бьёт по разработке с помощью ИИ: расплывчатый запрос порождает правдоподобно выглядящий код, который может не соответствовать тому, что на самом деле требовалось, и нет ничего конкретного, по чему его можно проверить.
##Solution
Зафиксируйте задуманное поведение в ясной, версионируемой спецификации — сценарии, критерии приёмки и контракты — и относитесь к ней как к источнику истины. Генерируйте или направляйте реализацию (нередко с помощью ИИ) из спецификации, выводите из той же спецификации тесты на соответствие и проверяйте реализацию по ним.
Когда поведение нужно изменить, вы сначала меняете спецификацию, а реализация и тесты следуют за ней. Именно спецификацию, а не код, команда рассматривает на ревью и о ней спорит.
##Structure
- Спецификация — намерение, сценарии, критерии приёмки и контракты/схемы, хранимые под контролем версий.
- Генерация / реализация — код, произведённый или направленный так, чтобы удовлетворить спецификацию.
- Тесты на соответствие — проверки, выведенные из спецификации, которые реализация обязана пройти.
- Цикл обратной связи — расхождения обновляют спецификацию, которая заново задаёт код и тесты.
##Applicability
- Применяйте её для разработки с помощью ИИ, где точная спецификация превращает расплывчатый запрос в проверяемое намерение.
- Применяйте её для API, проектируемых от контракта, координации между несколькими командами и регулируемых или аудируемых систем.
- Избегайте тяжеловесных спецификаций для крошечных скриптов или исследовательских прототипов, где они стоят больше, чем дают.
##How to Implement
- Напишите спецификацию: намерение, конкретные сценарии, критерии приёмки и любые контракты или схемы.
- Проведите её ревью с заинтересованными сторонами — именно здесь разрешаются разногласия.
- Выведите из сценариев приёмочные / проверочные тесты на соответствие.
- Реализуйте код так, чтобы удовлетворить спецификацию, нередко с помощью ИИ, направляемого спецификацией.
- Запускайте тесты на соответствие; трактуйте падения либо как баги, либо как сигнал уточнить спецификацию.
- Сохраняйте спецификацию авторитетной — обновляйте её первой всякий раз, когда меняется поведение.
##Pros & Cons
- Единый, поддающийся ревью источник истины делает намерение явным.
- Естественно сочетается с генерацией кода ИИ, превращая запросы в проверяемые контракты.
- Соответствие можно проверять автоматически, снижая расхождение.
- Решения обсуждаются на уровне спецификации, до написания кода.
- Реальные предварительные усилия на написание и поддержку спецификации.
- Спецификации устаревают и вводят в заблуждение, если их не держать в синхронизации с реальностью.
- Инструментарий и соглашения всё ещё формируются.
- Переспецификация может быть так же вредна, как и недостаточная спецификация.
