---
title: "التطوير المدفوع بالمواصفات"
type: "architectural-pattern"
slug: "spec-driven-development"
url: "http://localhost:3000/ar/architectural-patterns/spec-driven-development.md"
also_known_as: "SDD"
description: "اكتب مواصفة صريحة وموثوقة أولاً، ثم انطلق منها في التنفيذ والاختبارات والكود المُولَّد — محافظاً على المواصفة بوصفها المصدر الوحيد للحقيقة."
languages: ["typescript"]
---
# التطوير المدفوع بالمواصفات

_Also known as: SDD_

> اكتب مواصفة صريحة وموثوقة أولاً، ثم انطلق منها في التنفيذ والاختبارات والكود المُولَّد — محافظاً على المواصفة بوصفها المصدر الوحيد للحقيقة.

## Intent

جعل المواصفة الدقيقة المصنوعَ الأساسيَ للتطوير. يُشتق التنفيذ والاختبارات وحتى الكود المُولَّد بالذكاء الاصطناعي من المواصفة ويُتحقق منها، بدلاً من أن تكون المواصفة وثيقةً تُرمى جانباً تُكتب قبل العمل «الحقيقي».

## Problem

تعيش المتطلبات عادةً في أذهان الناس أو خيوط المحادثات أو وثائق متقادمة. يتباعد التنفيذ عن النية، وحين يحدث ذلك لا يوجد مرجع موثوق لتحديد ما يجب أن يفعله النظام _فعلاً_.

يتجلى ذلك أشد ما يكون مع البرمجة المدعومة بالذكاء الاصطناعي: أمر مبهم ينتج كوداً يبدو معقولاً لكنه قد لا يطابق ما أُريد فعلاً، ولا يوجد شيء ملموس للتحقق منه.

## Solution

التقط السلوك المقصود في **مواصفة** واضحة ومُصدَّرة — سيناريوهات ومعايير قبول وعقود — وعاملها بوصفها مصدر الحقيقة. أنشئ التنفيذ أو وجّهه (في الغالب بمساعدة الذكاء الاصطناعي) _من_ المواصفة، واشتق **اختبارات المطابقة** من المواصفة ذاتها، وتحقق من التنفيذ مقابلها.

عندما يلزم تغيير السلوك، تُغيّر المواصفة أولاً وتترك التنفيذ والاختبارات تتبعها. المواصفة، لا الكود، هي ما تراجعه الفرق وتتجادل حوله.

## Structure

* **المواصفة** — النية والسيناريوهات ومعايير القبول والعقود/المخططات، محفوظة تحت إدارة النسخ.
* **التوليد / التنفيذ** — كود يُنتج أو يُوجَّه لإرضاء المواصفة.
* **اختبارات المطابقة** — فحوصات مشتقة من المواصفة يجب على التنفيذ اجتيازها.
* **حلقة التغذية الراجعة** — التناقضات تُحدّث المواصفة التي تُعيد قيادة الكود والاختبارات.

## Applicability

* استخدمه في **التطوير المدعوم بالذكاء الاصطناعي**، حيث تُحوّل المواصفة الدقيقة الأوامر المبهمة إلى نوايا قابلة للتحقق.
* استخدمه في **واجهات برمجية تعاقدية أولاً**، والتنسيق بين الفرق المتعددة، والأنظمة الخاضعة للتدقيق والتنظيم.
* **تجنب المواصفات الثقيلة** للسكريبتات الصغيرة أو الاستكشاف السريع، حيث تكلفتها أعلى من عائدها.

## How to Implement

1. اكتب **المواصفة**: النية والسيناريوهات الملموسة ومعايير القبول وأي عقود أو مخططات.
2. راجعها مع أصحاب المصلحة — هنا تُحسم الخلافات.
3. اشتق **اختبارات القبول / المطابقة** من السيناريوهات.
4. نفّذ ما يُرضي المواصفة، مستعيناً في الغالب بالذكاء الاصطناعي الموجَّه بالمواصفة.
5. شغّل اختبارات المطابقة؛ عامِل الإخفاقات إما على أنها أخطاء أو إشارات لتحسين المواصفة.
6. احتفظ بسلطة المواصفة — حدّثها أولاً في كل مرة يتغير فيها السلوك.

## Pros

* مصدر وحيد قابل للمراجعة للحقيقة يُبقي النية صريحة.
* يتكامل بشكل طبيعي مع توليد الكود بالذكاء الاصطناعي، محوّلاً الأوامر إلى عقود قابلة للتحقق.
* يمكن التحقق من المطابقة آلياً، مما يقلل من الانجراف.
* تُناقش القرارات على المواصفة، قبل كتابة الكود.

## Cons

* جهد أولي حقيقي لكتابة المواصفة وصيانتها.
* المواصفات تتقادم وتُضلل إن لم تُحافَظ على تزامنها مع الواقع.
* الأدوات والاصطلاحات لا تزال في طور النضج.
* الإفراط في التوصيف قد يضر بقدر ما يضر الإهمال.
## Relations

**Related patterns**

- [التطوير المدفوع بالاختبارات](/ar/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)
  })
}
```