مراجعات التصميم والعروض التفصيلية

مراجعات التصميم والعروض التفصيلية

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

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

لماذا تفشل المراجعات (وكيف تمنع ذلك)

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

الحل للإخفاقات الثلاث واحد: ميثاق مراجعة واضح يحدد النطاق، ونافذة قراءة مسبقة إلزامية لا تقل عن 48 ساعة، وسجل إجراءات رسمي يُحتفظ به طوال الجلسة ويُنشر فور انتهائها.

العرض التفصيلي المنظم

العرض التفصيلي هو مراجعة غير رسمية يقودها المصمم نفسه. يقدم المصمم التصميم لمجموعة صغيرة (3-5 أشخاص) ويسرده من البداية إلى النهاية، تماماً كما يصطحب المرشد السياحي الزوار في جولة عبر مبنى. يطرح الحاضرون أسئلة توضيحية ويرصدون المخاوف، لكن المؤلف يتحكم في الوتيرة وجدول الأعمال.

تناسب العروض التفصيلية:

• التصاميم المبكرة أو المسودات التي لا تزال قيد التطوير.
• الأنظمة الفرعية التي لا تحتاج إلى مشاركة أكثر من 2-3 أصحاب مصلحة.
• الفرق ذات الثقة العالية التي ترى في المراجعات الرسمية تعقيداً غير ضروري.

قد يسير عرض تفصيلي عملي لنظام حجز مواعيد عيادة طبية على النحو التالي: تقدم المحللة مخطط تفكيك الوحدات وتسرد كيف تستدعي مكونة PatientPortal واجهة برمجة AppointmentService التي تستعلم بدورها من SlotRepository. يلاحظ مطور أن مخطط التسلسل يظهر استدعاءً متزامناً قد ينتهي بانتهاء المهلة تحت الحِمل العالي — ينبغي أن يستخدم التصميم قائمة انتظار غير متزامنة لتأكيدات حجز المواعيد. يُسجَّل هذا الملاحظة كإجراء رقم 1: مراجعة تدفق تأكيد الموعد ليصبح غير متزامن؛ المسؤول: كبير المهندسين؛ الموعد: الجمعة.

مراجعة التصميم الرسمية

مراجعة التصميم الرسمية (التي تُسمى أحياناً فحص التصميم) هي عملية منظمة تفصل الأدوار، يديرها مُشرِّف مخصص — وليس المؤلف. تطبق المراجعات الرسمية قائمة تحقق لاكتشاف العيوب، وتتتبع كل مشكلة مقابل تقدير الخطورة، وتنتج سجل مراجعة موقعاً يصبح جزءاً من مسار المراجعة في المشروع.

الأدوار النموذجية في المراجعة الرسمية:

• المشرف — يخطط للجلسة ويطبق التأطير الزمني ويمتلك سجل الإجراءات. يُفضَّل أن يكون محللاً ذا خبرة لم يشارك في صياغة التصميم.
• المؤلف (أو المؤلفون) — يقدمون ويوضحون؛ لا يدافعون. يستمع المؤلف أكثر مما يتكلم.
• المراجعون (2-4) — نظراء تقنيون، ومحلل متطلبات، وممثل عن الفريق الذي سيختبر النظام أو ينشره.
• الكاتب — يسجل كل مشكلة في الوقت الفعلي؛ يمكن أن يكون مراجعاً يأخذ الملاحظات أيضاً.

المراجعة مقابل المتطلبات: أسلوب قائمة التحقق

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

في منصة لوجستية إلكترونية قد تتضمن القائمة صفوفاً مثل:

• المتطلب REQ-007 "يجب أن يعرض النظام وقت التسليم المتوقع في غضون ثانيتين" → مربوط بخدمة DeliveryEstimator وطبقة تخزين Redis مؤقت → يتحقق المراجعون: هل يتضمن التصميم التخزين المؤقت فعلاً، وهل SLA الثانيتين مذكور في مواصفات واجهة برمجة التطبيق؟
• المتطلب REQ-019 "فقط السائقون المصادق عليهم يمكنهم تحديث حالة الشحنة" → مربوط بـ AuthMiddleware و ShipmentController → يتحقق المراجعون: هل يُطبَّق حارس المصادقة على النقاط الطرفية الصحيحة؟

أي صف لا يتحقق بوضوح يصبح عيباً في سجل الإجراءات — وليس موضوع نقاش مستقبلي، بل بنداً ملموساً يجب حله قبل الموافقة على التصميم.

تصنيف خطورة العيوب

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

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

سجل الإجراءات

سجل الإجراءات هو المخرج الأهم من أي مراجعة. إنه سجل منظم يحتوي صفاً واحداً لكل مشكلة، يتضمن على الأقل:

• المعرّف — رقم تسلسلي فريد (AR-001، AR-002، …).
• الوصف — بيان واضح لا لبس فيه للمشكلة، وليس الحل.
• الخطورة — حرجة / رئيسية / ثانوية.
• مرجع المتطلب — معرف المتطلب الذي ينتهكه العيب أو يهدده.
• المالك — الشخص المسؤول عن المعالجة (عادةً المؤلف، لكن ليس دائماً).
• الموعد النهائي — مُتفق عليه في الاجتماع؛ لا يُترك مفتوحاً.
• الحالة — مفتوح / قيد التنفيذ / محلول / مُتحقق منه.

مثال على صفوف من سجل إجراءات مراجعة منصة لوجستية:

دراسة حالة المتجر الإلكتروني: اكتشاف ثغرة حرجة

يخطط متجر إلكتروني لإضافة وحدة نقاط الولاء. تحتوي وثيقة SRS على المتطلب REQ-044: "يجب أن تكون أرصدة النقاط متسقة عبر جميع الجلسات — العميل الذي يكسب نقاطاً عبر الهاتف يجب أن يرى الرصيد المحدث فوراً على الويب." يقترح فريق التصميم استعلاماً بسيطاً من جدول loyalty_points عند تحميل كل صفحة. يسأل مراجع يراجع القائمة: "يظهر التصميم استعلام قراءة واحداً، لكن المتطلب SRS يشترط تناسقاً فورياً عبر الجلسات. إذا كتبت جلستان في الوقت ذاته — إحداهما تستردّ نقاطاً والأخرى تكسبها — أيهما تسبق؟" يدرك المؤلف أن التصميم يخلو من قفل متفائل أو حدود معاملة ذرية حول عمليات النقاط. يُسجَّل ذلك كعيب حرج، ويُعدَّل التصميم لاستخدام معاملة مسلسلة، ويُوضع علامة "محقق" على الصف في القائمة بعد التحقق. لولا المراجعة، كانت حالة السباق هذه ستظهر كخطأ مرئي للعميل تحت الحِمل العالي.

ماذا يحدث بعد المراجعة

المراجعة لا تكتمل حين ينتهي الاجتماع — بل تكتمل حين يُغلق ويُتحقق من كل بند حرج ورئيسي في سجل الإجراءات. يصنّف المشرف المراجعة كـموافق عليها أو موافق عليها بشروط أو تتطلب إعادة مراجعة. حالة موافق عليها أو موافق عليها بشروط (حيث تكون الشروط ثانوية فقط) هي التي تُرخّص بدء مرحلة البناء. أما حكم تتطلب إعادة مراجعة فيعني أن المؤلف يجب أن يُعدّل التصميم ويقدمه لمراجعة رسمية ثانية — وهي تكلفة لا تزال أقل بكثير من اكتشاف العيوب ذاتها في مرحلة اختبار النظام.

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