ما المقصود بالتطوير القائم على المواصفات؟

مع توفُّر أدوات الذكاء الاصطناعي ومساعدي البرمجة، مثل GitHub Copilot من Microsoft وClaude Code من Anthropic وBob من IBM، انخفضت عوائق الدخول إلى مجال توليد التعليمات البرمجية. يمكن لوكيل ذكاء اصطناعي مدعوم بنماذج لغوية كبيرة (LLM) وتشغِّله نماذج ذكاء اصطناعي متقدمة تنفيذ سلسلة من المهام التكرارية في الوقت الفعلي، وكل ذلك انطلاقًا من مطالبة واحدة بلغة طبيعية يقدِّمها المستخدم.

بالنسبة إلى تطوير البرمجيات، فهذا يعني إمكانية تحسين سير عمل التطوير وأتمتته لبناء النماذج الأولية والميزات الجديدة واختبارات الوحدات وغير ذلك. لم يكن إنشاء التعليمات البرمجية أسهل من أي وقت مضى. ومع ذلك، هناك جانب محفوف بالمخاطر ينبغي لمطوِّري البرمجة بالجو العام الانتباه إليه: فالذكاء الاصطناعي لا يكون أفضل من التعليمات التي يتلقاها.

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

يمكن أن تتخذ الديون التقنية في التطوير المدعوم بالذكاء الاصطناعي عدة أشكال: 

• يحدث انحراف السياق (Context Drift) عندما يؤدي إصلاح خطأ في جزء من النظام، دون قصد، إلى تعطيل وظيفة في جزء آخر، وهو عرض شائع للتعليمات البرمجية التي تم إنشاؤها دون فهم كامل للنظام ككل. 
• تُعَد التجزئة (Fragmentation) مظهرًا شائعًا آخر، حيث تفشل الميزات التي تم إنشاؤها حديثًا في التوافق مع الأنماط البنائية المعتمدة، ما يؤدي تدريجيًا إلى إضعاف اتساق قاعدة التعليمات البرمجية وقابليتها للصيانة. 
• وهناك أيضًا تكلفة تشغيلية يجب أخذها في الاعتبار. فمن دون مواصفة واضحة ترتكز إليها عملية توليد التعليمات البرمجية، قد يجد المطورون أنفسهم عالقين في دورات طويلة من كتابة المطالبات وتعديلها. وقد يستهلك هذا النهج آلاف الرموز لمعالجة أخطاء كان من الممكن تجنُّبها بالكامل بوجود مواصفة محددة بوضوح. 

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

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

يوفر إعداد مواصفة رسمية مسبقًا للفريق مصدرًا موحَّدًا ومرجعيًا للحقيقة يحكم جميع مراحل دورة حياة تطوير البرمجيات (SDLC)، بغض النظر عمن يكتب التعليمات البرمجية. 

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

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

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

وتعمل الاختبارات المؤتمتة كحلقة وصل بين التوثيق والتنفيذ، وغالبًا ما يتم دمجها في مسار التكامل المستمر والتسليم المستمر (CI/CD) لضمان بقاء الجانبين متزامنين وقابلين للتنفيذ طوال دورة حياة التطوير. وهذا التوازن بين التنظيم والمرونة يجعل من التطوير القائم على المواصفات نهجًا عمليًا وقابلًا للتوسع بالنسبة إلى معظم الفِرق الهندسية.¹

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

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

وفي الواقع العملي، تتبنّى العديد من الفِرق أساليب هجينة، منها:

• التعامل مع المواصفات باعتبارها أصولًا قابلة للتراكم ومُدارة بالإصدارات، مثل سجلات القرارات البنائية (ADRs)، بدلًا من الحرص دائمًا على إبقائها محدَّثة بالكامل.
• استخدام أنظمة خارجية (مثل أدوات تتبُّع المشكلات) باعتبارها المصدر المرجعي للحقيقة، لإحداث فصل مقصود.
• تجنُّب الأتمتة المكثفة في المشروعات عالية التعقيد أو المشروعات التي يقودها المجتمع، حيث تكون الحاجة إلى التحكم الدقيق في التغييرات أمرًا بالغ الأهمية.

ويمتلك كل نهج نقاط قوة وحدودًا معينة؛ لذا فإن السياق أهم من الالتزام الصارم بأي نموذج واحد.

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

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

ولتوضيح شكل المواصفة الفعَّالة عمليًا، تأمل المثال التالي الخاص بميزة مصادقة المستخدم: 

أنت على وشك تنفيذ ميزة تسجيل دخول المستخدم لتطبيق ويب.  
استخدِم المواصفة التالية بوصفها مصدرك المرجعي الوحيد للحقيقة.  
ولا تفترض أي متطلب غير مذكور فيها. 
 
الميزة: تسجيل دخول المستخدم 
 
نظرة عامة: 
السماح للمستخدمين المسجَّلين بإجراء المصادقة بأمان باستخدام عنوان البريد الإلكتروني وكلمة المرور. 
 
معايير القبول: 
1. يجب أن يقبل نموذج تسجيل الدخول عنوان بريد إلكتروني وكلمة مرور. 
2. إذا كانت بيانات الاعتماد صحيحة، فيجب إعادة توجيه المستخدم إلى لوحة المعلومات.
3. إذا كانت بيانات الاعتماد غير صحيحة، فيجب عرض رسالة خطأ عامة دون تحديد الحقل غير الصحيح. 
4. يجب قفل الحساب لمدة 15 دقيقة بعد 5 محاولات تسجيل دخول فاشلة متتالية. 
5. يجب نقل كلمات المرور عبر HTTPS فقط، وعدم تخزينها مطلقًا بصيغة نصية غير مشفرة. 
 
خارج نطاق العمل: 
- تسجيل الدخول الاجتماعي (OAuth). 
- المصادقة متعددة العوامل. 
- آلية إعادة تعيين كلمة المرور. 
 
حالات الحافة: 
- اكتشاف الحقول الفارغة على جانب العميل قبل الإرسال. 
- إعادة توجيه الجلسات المنتهية إلى صفحة تسجيل الدخول مع عرض رسالة معلوماتية. 
- يجب أن يظل النموذج قابلًا للاستخدام حتى عند تعطيل JavaScript. 
 
لا تبدأ التنفيذ حتى تتأكد من فهمك لمعايير القبول.

تشبه هذه المواصفات الوظيفية التي يكتبها مديرو المنتجات، لكنها تركز بدقة على ما يجب أن يتضمنه التنفيذ، ومعايير القبول الخاصة به، وكيفية التعامل مع حالات الحافة بسلاسة.

في الغالب، يتم حفظ هذه المواصفة في مستودع المشروع (repo) على GitHub كملف Markdown مثل SPEC.md أو /docs/auth-login.md، مع إدارة إصداراته عبر Git جنبًا إلى جنب مع قاعدة التعليمات البرمجية. يمكن لوكيل البرمجة المدعوم بالذكاء الاصطناعي الوصول إليه من خلال قيام المستخدم بلصقه في المطالبة، أو بشكل أفضل عبر الإشارة إلى الملف باستخدام واجهة سطر الأوامر (CLI) ليقرأه الوكيل من دليل المشروع. على سبيل المثال: "نفِّذ الميزة الموصوفة في /docs/auth-login.md".

في مسارات العمل الأكثر أتمتة، يتم تمرير ملف المواصفات كجزء من مطالبة النظام أو نافذة السياق في بداية المهمة، ما يساعد على تزويد الوكيل بتعليماته قبل أن يبدأ العمل.

وبقدر ما يمكن أن يوفره لك التطوير القائم على المواصفات من وقت ويَحُدّ من الديون التقنية، فمن المهم أيضًا أن تتذكر إمكانية قضاء وقت مفرط في "المبالغة في الهندسة". إذا أمضيت ثلاثة أسابيع تناقش اسم مفتاح واحد في JSON أو نقاط نهاية API محددة لميزة قد يتم حذفها بعد شهر، فإن ذلك يتعارض مع الهدف من التطوير القائم على المواصفات. 

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

مع ظهور أدوات المساعدة على البرمجة المدعومة بالذكاء الاصطناعي، ألهم كلٌّ من التطوير القائم على الاختبار (TDD) والتطوير القائم على السلوك (BDD) موجة جديدة هي: التطوير القائم على المواصفات. فبينما يطلب التطوير القائم على الاختبار (TDD) من المطورين تحديد النتائج المتوقعة من خلال الاختبارات، ويطلب التطوير القائم على السلوك (BDD) منهم تحديد السلوك من خلال التعاون، يطرح التطوير القائم على المواصفات سؤالًا أكثر جوهرية أولًا: هل حددنا بوضوح ما الذي نبنيه ولمن نبنيه؟^{2، 3}

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