مراجعة الكود

مراجعة الكود هي فحص (غالبا ما يكون في شكل مراجعة الزملاء) كود مصدري للحاسب بطريقة منهجية. والغرض من هذه العملية هو اكتشاف وتصحيح خطأ برمجي تم إغفاله في مرحلة تطوير البرمجيات (علم حاسوب) الابتدائية، إضافة إلى تحسين جودة البرمجيات العامة ومهارات المطورين. وتتم المراجعات بأشكال عديدة مثل [البرمجة الثنائية pair programming]، ومراجعات البرمجيات غير الرسمية، و[الفحوصات inspections] الرسمية.[1]

مقدمة

غالبا ما تمكن عملية مراجعة الكود من العثور على الثغرات الأمنية vulnerabilities و القيام بإزالتها، مثل استغلال سلسلة التنسيق غير المتحكم فيها format string exploits، وحالة سباق، و[تسرب الذاكرة] وفيض الدارئ، وبهذه الطريقة يتم تحسين أمان البرنامج. ومخازن البرامج على الإنترنت المبنية على أباتشي سبفيرجن (مع برنامج Redmine أو Trac)، وMercurial، وGit أو أدوات أخرى تسمح لمجموعات الأفراد بمراجعة الكود بشكل تعاوني. وعلاوة على هذا، فالأدوات المحددة للمراجعة التعاونية للكود يمكن أن تسهل عملية مراجعة الكود.

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

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

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

الأنواع

تقع ممارسات مراجعة الكود في ثلاثة تصنيفات رئيسية: البرمجة الثنائية pair programming ومراجعة الكود الرسمية formal code review ومراجعة كود خفيفة lightweight code review..[1]

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

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

  • التتبع Over-the-shoulder - يبحث المطور عن المؤلف التالي له أثناء استعراض الأخير للكود
  • تمرير الرسالة- يرسل نظام إدارة كود المصدر الكود للمراجعين بشكل أوتوماتيكي بعد إكمال الفحص.
  • [البرمجة الثنائية Pair Programming]- يطور مؤلفان الكود معا في نفس ورشة العمل، وهذا العمل شائع في [البرمجة القصوى].
  • مراجعة الكود بأداة معينة Tool-assisted code review- يستخدم المؤلفون والمراجعون أدوات متخصصة م تصميمها من أجل مراجعة الزملاء للكود.

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

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

النقد

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

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

انظر أيضا

المراجع
  1. Kolawa, Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. صفحة 260. ISBN 0470042125. مؤرشف من الأصل في 09 ديسمبر 2017. الوسيط |CitationClass= تم تجاهله (مساعدة)
  2. Jones, Capers; Christof, Ebert (April 2009). "Embedded Software: Facts, Figures, and Future". IEEE Computer Society. مؤرشف من الأصل في 13 ديسمبر 2019. اطلع عليه بتاريخ 05 أكتوبر 2010. الوسيط |CitationClass= تم تجاهله (مساعدة)
  3. Ganssle, Jack (February 2010). "A Guide to Code Inspections" (PDF). The Ganssle Group. مؤرشف من الأصل (PDF) في 15 ديسمبر 2018. اطلع عليه بتاريخ 05 أكتوبر 2010. الوسيط |CitationClass= تم تجاهله (مساعدة)
  4. Jones, Capers (June 2008). "Measuring Defect Potentials and Defect Removal Efficiency". Crosstalk, The Journal of Defense Software Engineering. مؤرشف من الأصل في 11 يناير 2010. اطلع عليه بتاريخ 05 أكتوبر 2010. الوسيط |CitationClass= تم تجاهله (مساعدة)

    وصلات خارجية
    • بوابة برمجة الحاسوب
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.