قد ينتج مساعد الذكاء الاصطناعي شاشة مقنعة قبل أن يتفق الفريق على ما يحدث خلفها. يضغط العميل على زر الإرسال، فتظهر رسالة نجاح، ويبدو العرض جاهزًا. لكن ماذا يحدث إذا ضغط مرتين؟ وماذا لو حاول موظف غير مخوّل تنفيذ الإجراء؟ أو استقبلت خدمة خارجية الطلب ولم تُعد ردًا يؤكد النتيجة؟
من هذه الأسئلة أبدأ المراجعة. المثال التالي افتراضي: شركة خدمات تستقبل عملاء في السعودية ويتابع عملياتها فريق في مصر. أستخدمه لشرح طريقة مقترحة للمراجعة قبل الإطلاق، وليس للقول إن نظام عميل محدد اجتاز هذه الاختبارات بالفعل.
أحدد السلوك المطلوب قبل قراءة التنفيذ
لنفترض أن العميل يرفع مستندًا ثم يراجعه موظف ويعتمده. أحتاج أولًا إلى تحديد من يحق له الرفع والاعتماد، وكيف يرتبط المستند بالطلب الصحيح، وما الذي يراه العميل أثناء الانتظار. وإذا كان الاعتماد يرسل بريدًا أو ينقل الطلب إلى مرحلة أخرى، فهذه النتائج جزء من المتطلب، وليست تفاصيل نتركها للنهاية.
بعد ذلك أطلب تغييرًا محدودًا ينفذ جزءًا واضحًا من المسار. يسهل فهم التغيير الصغير ومناقشته والتراجع عنه. أما إضافة مكتبة جديدة أو تعديل قاعدة صلاحيات مشتركة، فتحتاج إلى تفسير مستقل. قلة أسطر الكود لا تعني وحدها أن الحل أوضح أو أكثر أمانًا.
أتتبع الصلاحية حتى الخادم
إخفاء زر الاعتماد عن بعض المستخدمين لا يثبت أن تنفيذ الاعتماد نفسه محمي. أتتبع الطلب من المتصفح إلى الخادم، وأراجع دور المستخدم وصلاحيته على هذا الطلب تحديدًا. وجود حساب موظف صالح لا يعني أن صاحبه يجب أن يصل إلى مستندات جميع العملاء.
تشمل الأمثلة التي أختبرها رقم طلب يخص عميلًا آخر، وجلسة انتهت صلاحيتها، وحساب موظف لا يملك حق الاعتماد. أراجع كذلك البيانات التي تصل إلى السجلات والإشعارات. قد يحتاج مسؤول الدعم إلى رقم يساعده على تتبع المشكلة، لكنه لا يحتاج بالضرورة إلى نسخة من المستند أو كل بيانات العميل داخل سجل الأخطاء.
أراجع نتائج الاختبار مقابل المتطلب
قد تكرر الاختبارات المكتوبة مع الكود الافتراض الخاطئ نفسه. لذلك أقارنها بالسلوك الذي اتفقنا عليه مسبقًا: يُعتمد المستند مرة واحدة، ويظهر التغيير للعميل الصحيح، ولا يؤدي فشل إرسال البريد إلى ضياع سجل الاعتماد.
في الخدمة الثنائية اللغة، أستخدم أسماء عربية وأسماء منشآت طويلة وأرقامًا مرجعية تجمع الحروف اللاتينية والعربية. أراجع أيضًا عرض التوقيت للمستخدمين في مواقع مختلفة. نجاح الشاشة مع بيانات إنجليزية قصيرة لا يثبت أنها مناسبة لبيانات الاستخدام الفعلية. ناقشت هذه النقطة بتفصيل أكبر في مقال مسارات العمل بالعربية والإنجليزية.
أجرب ما يحدث عندما تفشل إحدى الخطوات
أختبر تعطل خدمة البريد وتكرار طلب الاعتماد عمدًا. هل يرى الموظف أن الإشعار ما زال معلقًا؟ وهل يستطيع إعادة إرساله دون اعتماد المستند مرة أخرى؟ وهل توجد معلومات كافية لتفسير ما حدث بدل الاكتفاء برسالة عامة تقول إن هناك خطأ؟
هذه قرارات تخص سير العمل قبل أن تكون قرارات برمجية. يوضح مقال وصول حدث التكامل مرتين لماذا لا ينبغي أن ينتج عن التكرار إجراء تجاري جديد بالضرورة. وقبل الإطلاق أحتاج أيضًا إلى طريقة واضحة لتعطيل السلوك الجديد واستعادة النسخة السابقة عند الحاجة.
أسلّم نظامًا يمكن لشخص آخر فهمه
التسليم المفيد يشرح ما تغير، والافتراضات التي ما زالت قائمة، وطريقة إجراء الاختبارات المهمة، والتصرف المطلوب عند تعطل خدمة يعتمد عليها النظام. يمكن للمساعد كتابة مسودة هذا الشرح، لكنني أراجعها على ضوء الكود الفعلي والسلوك الذي شاهدته.
تؤكد إرشادات GitHub للاستخدام المسؤول لمساعد Copilot Chat أيضًا أهمية مراجعة المخرجات واختبارها. بالنسبة لي، تسريع التنفيذ لا يلغي مسؤولية فهم النتيجة وقبولها. وللاطلاع على طريقة تفكيري في ربط خطوات العمل، يمكن قراءة دراسة حالة OVZA.
أسئلة شائعة
هل يكفي نجاح العرض التجريبي لاعتماد الكود؟
لا. العرض يغطي عادة مسارًا مختارًا. تشمل المراجعة أيضًا الصلاحيات والمدخلات غير الصالحة وتكرار الإجراءات وتعطل الخدمات وطريقة التعافي.
هل يمكن للمساعد نفسه كتابة الكود والاختبارات؟
يمكنه المساعدة في الاثنين، لكن النتائج المتوقعة يجب أن تأتي من متطلبات واضحة جرى الاتفاق عليها بصورة مستقلة. أراجع حالات الاختبار بحثًا عن السيناريوهات الغائبة والافتراضات المشتركة الخاطئة.
هل تحتاج كل التغييرات إلى المراجعة نفسها؟
لا. تصحيح عبارة يختلف عن تعديل حالة دفع. أزيد عمق المراجعة عندما يمس التغيير الأموال أو الصلاحيات أو البيانات الشخصية أو أكثر من نظام متصل.