في الموضوع السابق كان الحديث عن مراجعة الكود من خلال استخدام طريقة فحص الكود. أما في هذا الموضوع، سوف يشرح لنا جيسون كوهين تطبيق الأسلوب الخفيف لمراجعة الكود والذي تم اعتماده عبر المؤسسة بأكملها في غضون 18 شهرًا.

ما معنى الأسلوب الخفيف لمراجعة الكود (lightweight)

بافتراض أنك وافقت على الحُجّة القائلة بأن مراجعة الكود جيدة ولكن فحص الكود بطريقة تفصيلية (وزن ثقيل) ليست عملية، فإن السؤال التالي هو: كيف نجعل مراجعة الكود عملية؟

سنستكشف أربع تقنيات (techniques) خفيفة الوزن:

• فوق الكتف (Over-the-shoulder): ينظر أحد المبرمجين للكود بينما يقوم المبرمج الذي كتب الكود بالمرور عليه وفتح ملفات مختلفة والإشارة إلى التغييرات وشرح ما فَعَله. إذا رأى المراجِع شيئًا خاطئًا صغيرًا فيمكن للمبرمج الذي كتب الكود إصلاح الكود مباشرة بينما يقوم المراجِع بمتابعة الإصلاح. أما الأخطاء التي تحتاج لتغييرات كبيرة ولا يحتاج المراجِع إلى المشاركة فيها فيتم تنفيذها في وقت لاحق. لهذا الإجراء إيجابيات وسلبيات وهي:
  • الإيجابيات: سهل التنفيذ – سريع الإكمال – قد يعمل عن بعد من خلال مشاركة سطح المكتب والمكالمات الجماعية.
  • السلبيات: قيام المراجع بمراجعة الكود على حسب سرعة كاتِب الكود – عادة لا يتم التحقق من أن الأخطاء قد تم إصلاحها بالفعل – من السهل تخطّي ملف تم تغييره عن طريق الخطأ – من المستحيل فرض الإجراء (process) – لا توجد معايير لقياس/تحسين الإجراء.
• تمرير البريد الإلكتروني (Email Pass-around): يقوم المبرمج الذي كتب الكود بإرسال الكود عبر البريد الإلكتروني إلى المراجعين حيث يقومون بفحص الأكواد وطرح الأسئلة والمناقشة مع المبرمج الذي كتب الكود والمبرمجين الآخرين واقتراح التغييرات. الصعوبة هنا تكون في تجميع الأكواد الأصلية والتغييرات عليها بحيث يستطيع المراجعون رؤية ماهي التغييرات والقيام بالمقارنة. إيجابيات وسلبيات هذا الإجراء هي:
  • الإيجابيات: سهل التنفيذ إلى حد ما – يصلُح مع المبرمجين عن بعد – من السهل إشراك أشخاص آخرين – لا يقاطِع المراجِعين – يمكن لنظام إدارة الكود (Source Code Management) بدء المراجعات تلقائيًا.
  • السلبيات: عادة لا يتم التحقق من أن الأخطاء قد تم إصلاحها بالفعل – كيف تعرف متى تكون المراجعة مكتملة؟ – من المستحيل معرفة ما إذا كان المراجعون يقومون فقط بحذف رسائل البريد الإلكتروني – لا توجد معايير لقياس/تحسين الإجراء.
• البرمجة الثنائية (Pair Programming): يقوم مبرمجان بكتابة الكود معًا على نفس الجهاز. أظهرت الدراسات أن هذه الطريقة في البرمجة فعّالة جدًا في اكتشاف الأخطاء وتعزيز نقل المعرفة. أيضًا يستمتع بعض المبرمجين حقًا بالقيام بذلك. الصعوبة هنا تكون في عدم قدرة المراجِع القريب جدًا من الكود على نقْد الكود من موقف جديد وغير متحيّز. كذلك بدلاً من أن يقضي المراجِع ما بين 15 إلى 30 دقيقة في مراجعة التغيير الذي استغرق أحد المبرمجين بضعة أيام لإجرائه، في البرمجة الثنائية يكون لديك مبرمجان اثنان في المهمة نفسها طوال الوقت. أما إيجابيات وسلبيات هذا الإجراء فهي:
  • الإيجابيات: ثبت أنه فعّال في العثور على الأخطاء وتعزيز نقل المعرفة – المراجِع قريب من الكود حتى يتمكن من تقديم مراجعة مفصلة – بعض المبرمجين يحبّون ذلك.
  • السلبيات: بعض المبرمجين لا يحبّون ذلك – المراجع قريب جدًا من الكود بحيث لا يمكنه رؤية المشكلات – يستهلك الكثير من الوقت – لا يصلُح مع المبرمجين عن بعد – لا توجد معايير لقياس/تحسين الإجراء.
• بمساعدة الأدوات (Tool-assisted): يستخدم المبرمجون الذين يكتبون الأكواد والمراجعون إلى أدوات متخصصة مصمّمة لمراجعة الأكواد ويشمل ذلك جمْع الملفات ونقلها وعرضها وكذلك التعليقات والأخطاء بين جميع المشاركين وجمْع المقاييس ومَنْح مديري المنتجات والمشرفين بعض التحكّم في سير العمل. المهم التأكّد من أن الأداة تتوافق مع سير العمل المطلوب وليس العكس. أيضًا يمكن أن تكون الأداة مفتوحة المصدر (open-source) أو برنامجًا تجاريًا (commercial software).

ماذا أفعل؟ أو ماهي الخطوة التالية؟

جميع التقنيات المذكورة أعلاه مفيدة وستؤدي إلى كود أفضل مما قد يكون لديك. لاختيار التقنية المناسبة لك، ابدأ بأعلى القائمة ثم انتقل إلى الأسفل. التقنيات الأولى هي الأبسط ولذلك إذا كنت على استعداد للتعايش مع الجوانب السلبية فتوقف عند هذا الحد. تتمتّع المراجعة المدعومة بالأدوات بأكبر قدر من الإمكانية لإزالة الجوانب السلبية ولكن سيتعيّن عليك الالتزام بفترة تجريبيّة وتحليل تنافسي (competitive analysis) وربما بعضًا من تخصيص الميزانية.

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

بالتوفيق للجميع…

* المصدر: https://www.methodsandtools.com/archive/archive.php?id=66

** الصورة من موقع: https://github.com