---
title: "Разработка на основе спецификации"
type: "architectural-pattern"
slug: "spec-driven-development"
url: "http://localhost:3000/ru/architectural-patterns/spec-driven-development.md"
also_known_as: "SDD"
description: "Сначала напишите явную, авторитетную спецификацию, а затем выводите из неё реализацию, тесты и генерируемый код — сохраняя спецификацию как единственный источник истины."
languages: ["typescript"]
---
# Разработка на основе спецификации

_Also known as: SDD_

> Сначала напишите явную, авторитетную спецификацию, а затем выводите из неё реализацию, тесты и генерируемый код — сохраняя спецификацию как единственный источник истины.

## Intent

Сделайте точную спецификацию основным артефактом разработки. Реализация, тесты и даже сгенерированный ИИ код выводятся из спецификации и проверяются по ней, вместо того чтобы спецификация была одноразовым документом, написанным перед «настоящей» работой.

## Problem

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

Сильнее всего это бьёт по разработке с помощью ИИ: расплывчатый запрос порождает правдоподобно выглядящий код, который может не соответствовать тому, что на самом деле требовалось, и нет ничего конкретного, по чему его можно проверить.

## Solution

Зафиксируйте задуманное поведение в ясной, версионируемой **спецификации** — сценарии, критерии приёмки и контракты — и относитесь к ней как к источнику истины. Генерируйте или направляйте реализацию (нередко с помощью ИИ) _из_ спецификации, выводите из той же спецификации **тесты на соответствие** и проверяйте реализацию по ним.

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

## Structure

* **Спецификация** — намерение, сценарии, критерии приёмки и контракты/схемы, хранимые под контролем версий.
* **Генерация / реализация** — код, произведённый или направленный так, чтобы удовлетворить спецификацию.
* **Тесты на соответствие** — проверки, выведенные из спецификации, которые реализация обязана пройти.
* **Цикл обратной связи** — расхождения обновляют спецификацию, которая заново задаёт код и тесты.

## Applicability

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

## How to Implement

1. Напишите **спецификацию**: намерение, конкретные сценарии, критерии приёмки и любые контракты или схемы.
2. Проведите её ревью с заинтересованными сторонами — именно здесь разрешаются разногласия.
3. Выведите из сценариев **приёмочные / проверочные тесты на соответствие**.
4. Реализуйте код так, чтобы удовлетворить спецификацию, нередко с помощью ИИ, направляемого спецификацией.
5. Запускайте тесты на соответствие; трактуйте падения либо как баги, либо как сигнал уточнить спецификацию.
6. Сохраняйте спецификацию авторитетной — обновляйте её первой всякий раз, когда меняется поведение.

## Pros

* Единый, поддающийся ревью источник истины делает намерение явным.
* Естественно сочетается с генерацией кода ИИ, превращая запросы в проверяемые контракты.
* Соответствие можно проверять автоматически, снижая расхождение.
* Решения обсуждаются на уровне спецификации, до написания кода.

## Cons

* Реальные предварительные усилия на написание и поддержку спецификации.
* Спецификации устаревают и вводят в заблуждение, если их не держать в синхронизации с реальностью.
* Инструментарий и соглашения всё ещё формируются.
* Переспецификация может быть так же вредна, как и недостаточная спецификация.
## Relations

**Related patterns**

- [Разработка через тестирование](/ru/architectural-patterns/test-driven-development.md)

## Code Examples

### typescript

```typescript
// Спецификация — источник истины: сценарии в виде данных.
export const slugifySpec = {
  name: 'slugify',
  cases: [
    { input: 'Hello World', expected: 'hello-world' },
    { input: 'A  B', expected: 'a-b' },
  ],
}

// Тест на соответствие, выведенный из спецификации — реализация обязана его удовлетворять.
for (const c of slugifySpec.cases) {
  test(`${slugifySpec.name}(${c.input})`, () => {
    expect(slugify(c.input)).toBe(c.expected)
  })
}
```