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