قبل أن ينفّذ وكيلٌ ميزةً معقّدة، علينا أن نتّفق على ما يجب أن تفعله هذه الميزة وكيف تتلاءم مع المشروع. وثيقة المواصفات المكتوبة تمنحنا شيئًا نناقشه ونعدّله معًا. في هذا الفيديو سنرى متى يستحق هذا الاتفاق أن نكتبه، وسنتناول النقاش نفسه، ثم التنفيذ والمراجعة اللذين يليانه، والخيار الأقصى: إعادة توليد الكود من مواصفات معدَّلة.
في برنامج صغير أو سكربت أو تجربة سريعة، يكفي أن تصفوا ما تريدونه، وتتركوا الوكيل يبنيه، ثم تفحصوا النتيجة. وإن كانت النتيجة خاطئة، تصلحونها، أو تتخلّصون منها وتحاولون من جديد. برمجيات كهذه لا تحتاج إلى مواصفات. فكتابة المواصفات مسبقًا تكلّف أكثر مما توفّر.
لكن البرمجيات تكبر، وكذلك الفرق التي تبنيها. النظام الأكبر فيه مكوّنات كثيرة، ويعمل عليه عدة أشخاص، وعدة وكلاء يعملون إلى جانبهم. كل تغيير الآن ينطوي على قرارات تتفاعل مع قرارات اتّخذها أشخاص آخرون ووكلاء آخرون. قبل البدء بالبناء، يحتاج الفريق إلى طريقة للاتفاق على ما يجب أن يفعله التغيير، وكيف يجب أن يسير العمل.
التطوير الموجَّه بالمواصفات (spec-driven development) ممارسة لإدارة هذا التعقيد. فيه يتّفق الأشخاص والوكلاء المعنيّون على السلوك المقصود وعلى القرارات المهمة في وثيقة مكتوبة، ثم يأتي التنفيذ بناءً عليها.
إحدى طرق العمل أن تصفوا ميزة، وتتركوا الوكيل ينفّذها، ثم تراجعوا الكود والسلوك. تشرحون ما يجب تغييره، وتعيدون الكرّة. هذه طريقة سليمة لتطوير البرمجيات. لكن حين تتضمّن الميزة عدة قرارات متفاعلة، قد ينتهي بكم الأمر إلى اكتشاف ما أردتموه بعد أن يكون الوكيل قد بنى شيئًا آخر.
التطوير الموجَّه بالمواصفات يضيف جولة مبكرة من النقاش والتعديل. تكتبون مسودة المواصفات، وتناقشون القرارات، وتعدّلون الوثيقة قبل أن تطلبوا التنفيذ. وبعد ذلك تظلّون تراجعون الكود وتحسّنونه. الفائدة أنكم تكونون قد عالجتم مسبقًا أسئلة مهمة حول ما يجب بناؤه.
والتنفيذ أيضًا يكشف لنا أمورًا جديدة. قيدٌ فاتنا، أو متطلّبٌ أعدنا النظر فيه، يعيدنا إلى المواصفات. هذه دورات عمل مترابطة، وما نكتشفه في الكود قد يحسّن النسخة التالية من المواصفات.
المواصفات تسجّل ما ننوي بناءه، ونطاقه وقيوده، وقرارات التصميم المهمة. كتابة المتطلبات قبل التنفيذ لها تاريخ طويل في تطوير البرمجيات. ووكلاء البرمجة يتيحون استخدامًا آخر لهذه الوثيقة: فالوكيل يستطيع أن يقرأها إلى جانب المشروع، ويعمل على التنفيذ الذي تصفه.
المواصفات تمنحكم أنتم وزملاءكم والوكيل أساسًا مشتركًا للعمل. يمكن للناس أن يعترضوا على قرار دون أن يستنتجوه من الكود أولًا. ومن المفيد أيضًا تسجيل سبب اتخاذ القرار المهم، لأن هذا الشرح هو بالضبط ما يحتاجه من يقترح تغييره لاحقًا.
ولأن الكود يُبنى من المواصفات، فالمواصفات هي التي تحدّد السلوك المقصود. فإذا خالف التنفيذ متطلّبًا ما زال ساريًا، فالتنفيذ هو الخاطئ. التوثيق المكتوب لاحقًا يصف ما بُني فعلًا. وحين يُهمَل، يبتعد عن الكود تدريجيًا، والوكيل الذي يقرؤه قد يسعى إلى سلوك لم يعد موجودًا في البرنامج. والمواصفات أيضًا تحتاج إلى صيانة حين تتغيّر المتطلبات. مرجعيّتها نابعة من أنها تحدّد السلوك المقصود، لا من مجرّد كونها وثيقة.
قد تصف المواصفات ميزةً في بضع مئات من الأسطر، بينما يمتد تنفيذها إلى آلاف أو عشرات الآلاف من الأسطر. المتطلبات مركّزة في مكان واحد، بينما يوزّع التنفيذ هذه القرارات على الدوال والملفات والاختبارات. وهذا يجعل المواصفات مكانًا مفيدًا لمراجعة السلوك المقصود معًا.
توليد الكود قد يكون سريعًا. لكن فهمه وفحصه ودمجه في المشروع وتغييره من جديد، كل ذلك يتطلّب جهدًا. حين نحسم قرارًا مهمًا في المواصفات، نتجنّب أن نبني ثم نعدّل كل الكود الذي يعتمد على القرار الخاطئ. ولهذا يستحق النقاش وقتنا قبل أي تنفيذ معقّد.
في نظام كبير، تصف المواصفات عادةً ميزةً أو تغييرًا محدود النطاق. لستم بحاجة إلى وصف النظام بأكمله قبل العمل عليه، وتنفيذ الميزة لا يعني إعادة توليد كل ما حولها. المشروع القائم هو نقطة البداية.
الميزات تتفاعل مع أجزاء أخرى من البرنامج. ونقاش المواصفات يجب أن يشمل الواجهات، والبيانات المشتركة، والسلوك القائم الذي يجب أن يستمر في العمل. وهذا يعني قراءة الكود ذي الصلة، وإشراك المسؤولين عن المكوّنات المتأثّرة. هنا يكتشف الفريق الافتراضات المتعارضة، ويتّفق على مكان الميزة في النظام.
الطلب القصير يترك قرارات غير مذكورة. وحين تصفون الميزة بعناية أكبر، تضطرون إلى التفكير في السلوك عند الفشل، وفي التوافق، وفي مسؤوليات المكوّنات المختلفة. كتابة المواصفات تُظهر هذه الأسئلة. والإجابة عن سؤال قد تكشف سؤالًا آخر لم تفكّروا فيه.
إن طلبتم من الوكيل أن يبني والأسئلة لم تُحسم بعد، فسيسألكم أحيانًا، وأحيانًا سيمضي بافتراضاته الخاصة. لذا من المجدي أن تجعلوا القرارات المهمة صريحةً قبل أن تطلبوا الكود. يمكنكم أيضًا ترك قرار لوقت لاحق. وعندها من المفيد أن تسجّلوه قرارًا مفتوحًا، مع ذكر الجزء من العمل الذي يتوقّف على حسمه.
إحدى الطرق السهلة للبدء أن تطلبوا من الوكيل أن يقرأ سياق المشروع ذا الصلة، ويساعدكم في صياغة المواصفات، وأن يطرح القرارات التي يجدها غير محسومة قبل تنفيذ أي شيء. ثم تناقشون هذه الأسئلة بوتيرة تسمح لكم بالتفكير جيدًا في الإجابات. وحين تحتاج القرارات إلى عناية دقيقة، اطلبوا أن يطرح سؤالًا واحدًا كل مرة.
ومع تقدّم النقاش، تعودون باستمرار إلى المسودة المكتوبة. يشرح الوكيل فهمه، وعواقب الخيارات المقترحة، وأنتم تصحّحون كل ما لا يطابق قصدكم. ومن المجدي تحديث الوثيقة أثناء هذا الحوار لا في نهايته، لأن قراءة المواصفات نفسها هي إحدى طرق اكتشاف السؤال التالي.
الغاية في هذه المرحلة فهمٌ مشترك لما سيُبنى تاليًا. أن تفهموا اقتراح الوكيل، وأن يطابق وصفه المكتوب ما تقصدونه، وأن يتّفق زملاؤكم على السلوك والقيود والفحوصات للخطوة التالية. أن يقول الوكيل إنه لم تعد لديه أسئلة لا يكفي وحده. الاتفاق يأتي من مراجعتكم أنتم لشرحه وللمواصفات.
ماذا تتضمّن المواصفات؟ لا توجد قائمة ثابتة، فاعتبروا ما يلي اقتراحًا. من الطبيعي أن نبدأ بالهدف والنطاق: ما الذي يتغيّر، وما الذي يقع خارج هذا الجزء من العمل. بعد ذلك يأتي السلوك الذي سيلاحظه الناس أو البرمجيات الأخرى، بما فيه الاستخدام العادي وحالات الفشل، والحالات الحدّية المهمة. وهذا ما يعطي القارئ صورة واضحة عمّا يُفترض أن تفعله الميزة.
وتسجّل المواصفات أيضًا كيف ترتبط الميزة بالمشروع القائم، وما القيود التي يجب أن تلتزم بها. وقرار التنفيذ مكانه هنا حين يعتمد عليه عمل آخر، أو حين يؤدّي تركه مفتوحًا إلى تصميم غير مناسب. وأسباب الخيارات المهمة مكانها هنا أيضًا، دون وصف كل سطر في الكود.
معايير القبول تصف كيف نتحقّق من وجود السلوك المطلوب، ومكانها في المواصفات كذلك. والقرارات التي ما زالت مفتوحة تبقى ظاهرة أيضًا، مع بيان متى يجب حسمها. هذه الأقسام نقطة بداية، لا قالب جاهز. والقدر المناسب من التفاصيل هو ما يتيح للناس فهم القرارات التي يحتاجها هذا التغيير ومراجعتها.
من المجدي حفظ المواصفات في نظام التحكم في الإصدارات، كالكود. عندها يظهر كل تعديل على شكل diff، وترون بالضبط أي القرارات تغيّرت. وهذا مهم لأن تغييرًا صغيرًا في المتطلبات قد يؤثّر في عدة أجزاء من التنفيذ. وبعد أن تتّفقوا على التغيير المقصود، يصبح هو الدليل لمراجعة الكود.
حين تُعتمد المواصفات، يتسلّم الوكيل الوثيقة وصلاحيات الوصول إلى المستودع المعني، وتطلبون منه تنفيذ الميزة داخل المشروع القائم. بدء ذلك في جلسة جديدة اختبار مفيد للوثيقة. فالجلسة الجديدة تتلقّى سياق المشروع والتعليمات السارية عليه، لكنها لم تشهد محادثة التصميم كي تكمل ما نسيتم كتابته من قرارات.
وما يعود به الوكيل يُراجَع في ضوء المتطلبات، وتُشغَّل عليه الفحوصات المتّفق عليها. ويجب أيضًا أن يتلاءم مع المشروع ويحافظ على السلوك الذي كان موجودًا. وحين يظهر عدم تطابق، يتوقّف الإصلاح على سببه. إن أخطأ التنفيذ في متطلّب واضح، فالتنفيذ هو ما يُصلَح، وإعادة كتابة المواصفات لتطابق هذا الخطأ لن تفعل سوى إخفاء المشكلة.
بعد تعديل المواصفات، يمكنكم أن تطلبوا من الوكيل تغيير التنفيذ الحالي. هذا يحافظ على الكود المفيد الذي يعمل، ويطبّق عليه القرارات الجديدة. وهذا الخيار نقطة بداية معقولة حين يظلّ التنفيذ ملائمًا للتصميم، وتكون التغييرات محدودة النطاق.
يمكنكم أيضًا أن تحذفوا تنفيذ الميزة، وتطلبوا من الوكيل أن يولّد تنفيذًا جديدًا من المواصفات المعدَّلة. وهذا منطقي حين تكون المحاولة الأولى قد صُمّمت على أساس افتراضات غيّرتموها الآن، وإصلاحها يعني العمل ضدّ تلك البنية.
قد يستوفي تنفيذان المواصفات نفسها ويختلفان مع ذلك في تصميمهما الداخلي. هذا لا بأس به، وهو يدلّكم على ما يجب حسمه: خيار التصميم يدخل في المواصفات حين يؤثّر في المتطلبات، أو في التكامل، أو في قيد مهم. ويمكن ترك بقية الخيارات مفتوحة. لكن التنفيذ الجديد قد يأتي بأخطاء مختلفة أيضًا، فالمساران يحتاجان إلى مراجعة واختبار.
حتى الآن، وجّهت المواصفات تطويرًا عاديًا. تتّفقون على المتطلبات في الوثيقة، ثم تنفّذون وتعدّلون الكود كالمعتاد.
بعض مؤيّدي التطوير الموجَّه بالمواصفات يذهبون بالفكرة أبعد من ذلك. فتصبح المواصفات هي المصدر الذي يُصان، ويُولَّد التنفيذ منها. وحين يريدون تغييرًا، يغيّرون المواصفات ويعيدون توليد الكود من الصفر. في هذه الصيغة، الإصلاحات اليدوية في الكود المولَّد ليست الطريقة الدائمة لتسجيل تغيير، لأن التوليد التالي قد يستبدلها.
وهذا التزام أقوى من كتابة مواصفات ميزة ومراجعتها. فهو يتطلّب الحفاظ على القرارات والفحوصات اللازمة لتوليد تنفيذ مقبول من جديد. ويمكن تطبيقه على ميزة أو مكوّن دون تطبيقه على النظام كله. ويمكنكم اتّباع التطوير الموجَّه بالمواصفات دون الذهاب إلى هذا الحدّ.
هناك الكثير مما يمكن قوله عن المواصفات، وما زال الجدل قائمًا حول مدى الأخذ بها. لكن ما نأمل أن تخرجوا به من هذا الفيديو أبسط. المواصفات أداة عمل مفيدة للاتفاق على ما سيُبنى قبل أن يبنيه الوكيل، ونأمل أن تجرّبوها في عملكم.