مراجعة الكود

الأنواع

وفي هذا الصدد، تقع ممارسات مراجعة الكود في ثلاثة تصنيفات رئيسية: البرمجة الثنائية pair programming

في هذا الإطار، فمراجعة الكود الرسمية، مثل [عملية تفتيش فاجان Fagan inspection]، تنطوي على عملية مفصلة وحذرة مع مشاركين متعددين ومراحل متعددة.

وفي السياق ذاته، تمرير الرسالة- يرسل نظام إدارة كود المصدر الكود للمراجعين بشكل أوتوماتيكي بعد إكمال الفحص.

ومن جهة أخرى، مراجعة الكود بأداة معينة Tool-assisted code review- يستعمل المؤلفون والمراجعون أدوات متخصصة م تصميمها من أجل مراجعة الزملاء للكود.

من جهة ثانية، وربما يسمى بعض هذه الأساليب «عمليات مراجعة» (غير رسمية) أو«نقد» (سريع وغير رسمي).

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

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

علاوةً على ذلك، التتبع Over-the-shoulder - يبحث المطور عن المؤلف التالي له أثناء استعراض الأخير للكود

في هذا الإطار، ومراجعة الكود الرسمية formal code review ومراجعة كود خفيفة lightweight code review.

إضافةً إلى ذلك، وكثير من الفرق التي تتحاشى استخدام مراجعة كود الزملاء التقليدية الرسمية تستعمل إحدى الأشكال المذكورة بأعلى للمراجعة الخفيفة كجزء من عمليتهم الطبيعية للتطوير. ولقد وجدت دراسة حالة لمراجعة الكود والتي تم نشرها في كتاب "Best Kept Secrets of Peer Code Review" أن المراجعات الخفيفة قد كشفت أخطاء برمجية تماثل عدد ما اكتشفته المراجعات الرسمية، إلا أنها كانت أكثر سرعة واقل تكلفة.

ومن جهة أخرى، [البرمجة الثنائية Pair Programming]- يطور مؤلفان الكود معا في نفس ورشة العمل، وهذا العمل شائع في [البرمجة القصوى].

مقدمة

وفي السياق ذاته، و[مراجعة الكود code reviewing software] الآلية تقلل من مهمة مراجعة أجزاء ضخمة من الكود التي يقوم بها مطور برمجيات من خلال مراجعة منظمة لكود المصدر بحثا عن ثغرات أمنية معروفة.

إضافةً إلى ذلك، غالبا ما تمكن عملية مراجعة الكود من العثور على الثغرات الأمنية والقيام بإزالتها، مثل استغلال سلسلة التنسيق غير المتحكم فيها مثل هجمات ثغرة سلسلة التنسيق، وحالة سباق، وتسرب الذاكرة, وتجاوز سعة المخزن المؤقت، وبهذه الطريقة يتم تحسين أمان البرنامج. ومخازن البرامج على الإنترنت المبنية على مثل أباتشي سبفيرجن وغيت (برنامج) وميركوريال، إلى جانب أدوات إدارة المشاريع مثل Redmine وTrac أو أدوات أخرى تسمح لمجموعات الأفراد بمراجعة الكود بشكل تعاوني. وعلاوة على هذا، فالأدوات المحددة للمراجعة التعاونية للكود يمكن أن تسهل عملية مراجعة الكود.

من جانب آخر، وتشير الدراسات إلى أن المعدل الفعّال لمراجعة الكود يتراوح بين 200 و400 سطر من الشفرة في الساعة من الكود في الساعة. وفحص ومراجعة أكثر من بضع مئات من سطور الكود في الساعة الواحدة بالنسبة للبرامج الحاسمة (مثل [البرنامج المضمن embedded software] الحاسم للأمان) ربما يكون سريعا للغاية لدرجة أنه لا يكتشف أخطاء. وتشير بيانات الصناعة إلي أن مراجعة الكود يمكن أن تحقق على الأكثر معدل 85% لإزالة الخلل بمتوسط معدل يصل إلي نحو 65%.

من جهة ثانية، وتحليل Capers Jones المستمر لما يزيد عن 12.000 مشروع تطوير برمجيات قد أظهر أن معدل اكتشاف الخلل الكامن في الفحص الرسمي يتراوح بين 60 إلي 65%. وبالنسبة للفحص غير الرسمي، فالرقم هو أقل من 50%. ومعدل اكتشاف الخلل الكامن لأغلب أشكال الاختبار هو قرابة 30%.

النقد

وعلى صعيد آخر، تاريخيا، اكتسبت مراجعات الكود استثمارا معقولا في الإعداد لحدث المراجعة وزمن التنفيذ.

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

كذلك، ويعتقد البعض أن الاستخدام الماهر والمنضبط لعدد من أعمال التطوير يمكن أن تنتج عنه معدلات مرتفعة لاكتشاف أو تجنب الخلل الكامن. وعلاوة على هذا، فأنصار إكس بي XP(البرمجية القصوى) ربما يجادلون أن وضع ممارسات إضافية للبرمجة القصوى، مثل إعادة هيكلة الكود و[التطوير المعتمد على الفحص test-driven development] سوف يتسبب في وجود مستويات خلل كامنة تماثل ما يمكن تحقيقه من خلال المداخل الأكثر تقليدية، بدون الاستثمار.

• انظر كذلك
• فحص برمجي
• تنقيح برمجي
• فحص البرمجيات