لا تكتب البرمجيات مرتين: التطوير الموجَّه بالمواصفات ونهاية إعادة الكتابة
لماذا كُتبت البرمجيات دائماً مرتين، مرة في المواصفات ومرة كشفرة، ولماذا تزول تلك الكتابة الثانية أخيراً.
في تطوير البرمجيات، إذا أُنجز بشكل صحيح، علينا أن نكتب البرمجيات مرتين: أولاً في مواصفات مفصّلة تشرح بالضبط ما ينبغي أن تفعله البرمجية، ثم مرة أخرى كشفرة تُحقّق تلك المواصفات. لكن إليك الحقيقة القاسية: نادراً ما يُنجز هذا بشكل صحيح في المرة الأولى.
تتفكك العملية كثيراً، لأن إنشاء مواصفات شاملة يستغرق وقتاً، والفرق نادراً ما تجمع كل التفاصيل التي تحتاجها مقدماً. وهذا يؤدي إلى ثغرات وافتراضات وتصحيحات مكلفة. والنتيجة أن المشاريع تتجاوز الموازنة وتفوّت المواعيد وتترك الجميع محبَطاً.
التكاليف الخفية لكتابة البرمجيات مرتين
لفهم لماذا الكتابة مرتين ضرورية لكنها نادراً ما تُنجز جيداً، لنفصل المرحلتين.
1. الكتابة الأولى: مواصفات بلغة طبيعية
في المرة الأولى التي تكتب فيها البرمجية، لا تكتب شفرة على الإطلاق. تظهر المتطلبات وقصص المستخدمين ووثائق التصميم، مكتوبة بلغة طبيعية. وهنا تعرّف الفرق كيف ينبغي أن تعمل البرمجية، وما يستطيع المستخدمون فعله، وكيف ينبغي أن تكون التجربة.
لكن إليك المشكلة: لا فريق يملك رفاهية كتابة كل التفاصيل. فمسؤولو المنتج مضطرون كثيراً إلى الاستعجال ليلتزموا بمواعيد ضيقة، وبعض المشاريع لا تملك دوراً مهنياً للمنتج أصلاً. فتُرسَم الخطوط العريضة، لكن خصائص وتفاعلات مهمة تفوت. قال Steve Jobs جملته الشهيرة: «المنتجات العظيمة تأتي من 5000 قرار صغير»، لكننا في معظم المشاريع لا نتخذ تلك القرارات مقدماً. تُترَك لتفسير الهندسة لاحقاً، وهذا يؤدي إلى الخطوة الثانية.
2. الكتابة الثانية: ترجمة المواصفات إلى شفرة
حين تُسلَّم المواصفات، تصبح الهندسة مسؤولة عن تحويل تلك التعريفات إلى شفرة تعمل. لكن حين تكون الكتابة الأولى ناقصة، عليها استخدام الخيال لسد الثغرات. فتنشأ افتراضات، وحتى لو أتقن المهندسون التقنية فقد لا يملكون الصورة الكاملة لرؤية المنتج.
وهنا تظهر المشكلات إلى السطح:
- التفاصيل الناقصة تخلق احتكاكاً: حين لا تعرّف فرق المنتج خصيصة أو استخداماً مهماً، على الهندسة أن تحدس أو ترتجل. وهذا يعطي غالباً وظيفة لا تلبّي التوقعات.
- الافتراضات تؤدي إلى تصحيحات: حين تسد الهندسة الثغرات، قد تبني خصائص بشكل متناقض مع رؤية المنتج، فتسبب تصحيحات كبيرة في وقت لاحق من المشروع.
- تبادل اللوم يصبح محتوماً: حين تنزلق المواعيد وتنفلت الموازنات، ترمي الفرق اللوم على بعضها. تلوم فرق المنتج الهندسة على «عدم الفهم»، وتشير الهندسة إلى مواصفات مبهمة.
والنتيجة سلسلة من المشكلات تؤدي إلى مواعيد فائتة وموازنات متجاوزة ونتائج غير مُرضية. وتُظهر دراسة CHAOS من Standish Group سنوات أن معظم المشاريع تتجاوز الموازنة وتفوّت مواعيد التسليم. ووجدت دراسة من McKinsey مع جامعة أكسفورد أن مشاريع تقنية المعلومات الكبيرة تتجاوز الموازنة بمعدل 45 بالمئة والوقت بـ 7 بالمئة، مع تسليم قيمة أقل بـ 56 بالمئة من المتوقع، وأن 17 بالمئة من مشاريع تقنية المعلومات الكبيرة تسير بسوء يهدد وجود الشركة.
من الواضح أن شيئاً في هذه العملية مكسور.
لهذه الممارسة اسم الآن
اتفق القطاع على مصطلح، بينما كان معظم الناس يتجادلون في التوجيهات: التطوير الموجَّه بالمواصفات. اكتب المتطلبات والقيود ومعايير النجاح أولاً. وتعامل مع تلك المواصفة كمصدر الصحة. ودع الوكيل يبني مقابلها.
أطلقت GitHub منتج Spec Kit. وأطلقت AWS منتج Kiro. وقدّم كل من BMAD-METHOD و OpenSpec و Tessl محاولة. وكتب Martin Fowler عن ذلك. والتقارب ليس مصادفة: إنه ما يحدث حين تكتشف فئة كاملة شكل العطل نفسه في اللحظة نفسها.
وشكل العطل ذاك وُصف أعلاه. فالأدوات التي تبدأ من التوجيه تتجاوز الكتابة الأولى تماماً. تذهب مباشرة إلى الثانية، وتحدس في كل قرار لم تتخذه المواصفة قط. وهذا مقبول لعرض، ومدمّر لمنتج.
والتطوير الموجَّه بالمواصفات لا يلغي الكتابة الأولى. إنه يجعلها الكتابة الوحيدة التي تطلب حكماً بشرياً.
الكتابة الأولى الجديدة: مواصفات يمكنك إتمامها فعلاً
هذا ما يتغيّر. فسبب عدم كتابة أحد مواصفات كاملة لم يكن قلة الرغبة أبداً: كان العمل أبطأ من أن يبرر نفسه. أسابيع من الاستكشاف لوثيقة تشيخ عند أول تماس مع أول دورة عمل. فكتبت الفرق خطوطاً عريضة وتركت الـ 5000 قرار الصغير لتُكتشَف لاحقاً، تفسيراً بتفسير.
وحين يستغرق إعداد مواصفة ساعات لا أشهراً، ينقلب الحساب. فتستطيع أن تحمّل نفسك استنفاد الموضوع. المتطلبات الوظيفية والتصميم البصري ونموذج البيانات والحالات الحدّية، مجموعة قبل فتح المحرر ورخيصة بما يكفي لتصحيحها حين تتعلم شيئاً.
وهذا الجزء الأخير مهم. فالمواصفة التي لا تستطيع تصحيحها برخص تصبح كذبة لحظة يأتي الواقع. وهذا هو الحدس نفسه خلف البناء بـواجهة البرمجة أولاً: اتخاذ القرارات الحاملة جيداً قبل أن يكتب أحد شاشة؛ والبقية تتبع.
الكتابة الثانية الجديدة: توليد شفرة لا ترجمة
حين تكون المواصفة كاملة، تكفّ الكتابة الثانية عن كونها مشكلة ترجمة. تصبح مشكلة توليد. لغات قياسية: JavaScript و TypeScript و Python. وأطر قياسية: React و Next.js. شفرة حقيقية بأشكال تعرفها الهندسة أصلاً، مستنبطة من وثيقة اتخذت كل قرار مسبقاً.
والفرق ليس أن الهندسة تعمل أسرع. الفرق أنها تكفّ عن أداء الجزء الذي لم يكن هندسة قط: التكرار الآلي لقرارات اتخذها شخص آخر مسبقاً.
ما يتغيّر بعد ذلك
ثلاثة أمور تتغيّر معاً:
- الكتابة الأولى تُنجَز: حين يكلّف عمل المواصفة ساعات لا أشهراً، تستطيع الفرق تحميل نفسها اتخاذ القرارات الصغيرة مقدماً بدل اكتشافها في المراجعة.
- لا أحد يسد الثغرات: فالشفرة المُولَّدة من مواصفة كاملة لا تطلب من أحد حدس ما قصده فريق المنتج. والحدس كان دائماً مصدر العيوب.
- التصحيحات تكفّ عن التراكم: فالنية والتنفيذ يبدآن متوافقين. وما كان إعادة كتابة يصبح تغييراً واحداً في المواصفة.
مستقبل كتابة البرمجيات: اللغة الطبيعية
منذ أن أطلق البشر برمجيات، طلب العمل كتابتها مرتين: مرة بلغة طبيعية ومرة كشفرة. ولم تكن تلك الكتابة الثانية الجزء القيّم قط. كانت رسم مرور دفعناه لأنه لم تكن هناك طريق أخرى.
وهذه هي الحركة التي يُنظَّم حولها الجيل التالي من مُولِّدات التطبيقات بالذكاء الاصطناعي: الوضوح قبل الشفرة. عرّف التطبيق كمخطط، وأرسِ البنية جيداً، ودع الشفرة تُولَّد مقابلها. ليس اختصاراً يتجاوز عمل التعريف، بل سبباً لإنجازه أخيراً كما يجب.
وهناك طريق آخر الآن. فالبرمجيات كان ينبغي أن تُكتَب مرة واحدة دائماً.
قراءات ذات صلة
الدليل الكامل لهذه الممارسة: التطوير الموجَّه بالمواصفات. ولماذا تجاوز الجيل الذي يبدأ من التوجيه هذه الخطوة في vibe coding أخلف وعده، وما احتل مكانه في ما يأتي بعد vibe coding.
الأسئلة الشائعة
ما هو التطوير الموجَّه بالمواصفات؟ التطوير الموجَّه بالمواصفات يعني كتابة المتطلبات والقيود ومعايير النجاح قبل توليد أي شفرة، والتعامل مع تلك المواصفة كمصدر الصحة الذي يبني وكيل الذكاء الاصطناعي مقابله. وقد ظهر في 2025 كرد مباشر على طرق العمل التي تبدأ من التوجيه وتتجاوز خطوة التعريف تماماً.
كيف يختلف التطوير الموجَّه بالمواصفات عن كتابة وثيقة متطلبات كلاسيكية؟ الوثيقة هي الفكرة نفسها؛ والاقتصاد ليس كذلك. فالمواصفات الكلاسيكية كانت مكلفة إلى حد بعيد، فكتبت الفرق خطوطاً عريضة واكتشفت الباقي في مراجعة الشفرة. وحين تستغرق المواصفة ساعات لا أشهراً وتكون رخيصة التصحيح، فإتمامها يستحق، وإبقاؤها محدّثة يستحق.
أي الأدوات تدعم التطوير الموجَّه بالمواصفات؟ GitHub Spec Kit و AWS Kiro و BMAD-METHOD و OpenSpec و Tessl تنفيذات مسمّاة، ويدعم Cursor صيغة أخف عبر ملفات القواعد. وتختلف جوهرياً في مدى إحكام ربط المواصفة بالشفرة: هل تدفع التوليد مرة واحدة، أم تتطور بجانب الشفرة، أم هي الناتج الوحيد الذي تعدّله؟
هل يبطّئ التطوير الموجَّه بالمواصفات الفرق؟ ينقل العمل ولا يضيفه. فالقرارات المجموعة في المواصفة يتخذها أحد على أي حال: إما بوعي مقدماً وإما بصمت حين تحدس الهندسة أو النموذج لاحقاً. والطريق الثاني هو مصدر التصحيحات.
ماذا يحدث للهندسة إذا كانت الشفرة تُولَّد من المواصفة؟ يزول التكرار الآلي لقرارات شخص آخر. ولا يزول الحكم في البنية والمبادلات والصحة وما لا يُبنى. فهذه كانت دائماً الأجزاء التي تطلب مهندساً.
