دين المواصفات لا يختفي عند إصلاحه، بل ينتقل.
إصلاح المشكلة لا يعني القضاء عليها دائمًا. أحيانًا، أنت فقط تنقلها إلى مكان آخر.
قمت مؤخرًا بمراجعة مشروع للبحث عن "دين المواصفات" (spec debt). وهي عبارة عن فجوات في التعليمات تؤدي إلى أخطاء برمجية (bugs) أو سلوك سيئ للذكاء الاصطناعي. قمت بإصلاح سبعة عناصر محددة. وبعد الإصلاحات، اجتازت الاختبارات بنجاح. بدا كل شيء يسير على ما يرام.
لكن الدين لم يختفِ؛ بل انتقل من ملفات الميزات (feature files) إلى تعريفات الخطوات (step definitions).
إليك ما تعلمته من إصلاح هذه العناصر:
- الدقة مهمة. بدلاً من قول "الاستجابة سريعة"، قل "تعود الاستجابة في غضون 12 ثانية من إرسال الطلب". هذا يحدد التوقيت بدقة.
- تجنب الغموض. عبارة "أُعيدت المحاولة مرتين" غير واضحة. هل يعني ذلك محاولتين إجمالاً أم ثلاث محاولات؟ استخدم "لا يزيد عن طلبين لعملية الدفع إجمالاً" لضمان اليقين.
- حدد الآلية. قول "يتم تحرير المخزون" أمر غامض. حدد أن "خدمة المخزون (inventory service) تتلقى طلب تحرير للعنصر X".
- أزل الضمانات الزائفة. إذا اجتازت خطوة ما الاختبار لأن الميزة غير موجودة بعد، فقم بإزالة تلك الخطوة. فالاختبار الناجح لمسار غير موجود هو مجرد كذبة.
- عرّف معنى "الصحيح". لا تستخدم أبدًا كلمات مثل "صحيح" أو "مناسب" دون قيم محددة. استخدم "يحتوي على order_id 123" بدلاً من "يحتوي على المعرف الصحيح".
لقد قمت ببناء إطار عمل لاكتشاف هذه المشكلات. اطرح هذه الأسئلة الخمسة لكل سيناريو:
- من المسؤول عن هذا السيناريو؟
- ما هي القرارات التي يتركها هذا السيناريو مفتوحة؟
- هل جميع المصطلحات معرفة هنا؟
- هل يصف هذا السلوك أم التنفيذ؟
- ما الذي ينقص هذا الوصف؟
الفخ الأكبر هو الفجوة بين النص والكود. يمكنك كتابة تعليمات مثالية ودقيقة في مواصفاتك، ولكن إذا كان الكود الأساسي يستخدم طريقًا مختصرًا لاجتياز ذلك الاختبار، فستظل تعاني من الدين.
تقول المواصفات "إنشاء طلب عبر API". لكن الكود في الواقع يقوم فقط بحقن طلب مباشرة في قاعدة البيانات لتوفير الوقت. ينجح الاختبار، ولكن الدين انتقل من المتطلبات إلى التنفيذ.
لا تحاول كتابة مواصفات مثالية من المرة الأولى. اكتبها، وراجعها، ثم أصلحها.
المصدر: https://dev.to/diyaburman/spec-debt-doesnt-disappear-when-you-fix-it-it-migrates-d25
مجتمع تعليمي اختياري: https://t.me/GyaanSetuAi