|
تضامنًا مع حق الشعب الفلسطيني |
مراجعة الكود
مراجعة الكود هي فحص (غالبا ما يكون في شكل مراجعة الزملاء) كود مصدري للحاسب بطريقة منهجية. والغرض من هذه العملية هو اكتشاف وتصحيح خطأ برمجي تم إغفاله في مرحلة تطوير البرمجيات (علم حاسوب) الابتدائية، إضافة إلى تحسين جودة البرمجيات العامة ومهارات المطورين. وتتم المراجعات بأشكال عديدة مثل [البرمجة الثنائية pair programming]، ومراجعات البرمجيات غير الرسمية، و[الفحوصات inspections] الرسمية.[1]
مقدمة
غالبا ما تمكن عملية مراجعة الكود من العثور على الثغرات الأمنية vulnerabilities والقيام بإزالتها، مثل استغلال سلسلة التنسيق غير المتحكم فيها format string exploits، وحالة سباق، و[تسرب الذاكرة] وفيض الدارئ، وبهذه الطريقة يتم تحسين أمان البرنامج. ومخازن البرامج على الإنترنت المبنية على أباتشي سبفيرجن (مع برنامج Redmine أو Trac)، وMercurial، وGit أو أدوات أخرى تسمح لمجموعات الأفراد بمراجعة الكود بشكل تعاوني. وعلاوة على هذا، فالأدوات المحددة للمراجعة التعاونية للكود يمكن أن تسهل عملية مراجعة الكود.
و[مراجعة الكود code reviewing software] الآلية تقلل من مهمة مراجعة أجزاء ضخمة من الكود التي يقوم بها مطور برمجيات من خلال مراجعة منظمة لكود المصدر بحثا عن ثغرات أمنية معروفة.
وتحليل Capers Jones المستمر لما يزيد عن 12.000 مشروع تطوير برمجيات قد أظهر أن معدل اكتشاف الخلل الكامن في الفحص الرسمي يتراوح بين 60 إلي 65%. وبالنسبة للفحص غير الرسمي، فالرقم هو أقل من 50%.[2] ومعدل اكتشاف الخلل الكامن لمعظم أشكال الاختبار هو حوالي 30%.[3]
والمعدلات المثالية لمراجعة الكود هي حوالي 150 سطر من الكود في الساعة. وفحص ومراجعة أكثر من بضع مئات من سطور الكود في الساعة الواحدة بالنسبة للبرامج الحاسمة (مثل [البرنامج المضمن embedded software] الحاسم للأمان) ربما يكون سريعا للغاية لدرجة أنه لا يكتشف أخطاء.[4] وتشير بيانات الصناعة إلي أن مراجعة الكود يمكن أن تحقق على الأكثر معدل 85% لإزالة الخلل بمتوسط معدل يصل إلي حوالي 65%.[5]
الأنواع
تقع ممارسات مراجعة الكود في ثلاثة تصنيفات رئيسية: البرمجة الثنائية 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] سوف يتسبب في وجود مستويات خلل كامنة تماثل ما يمكن تحقيقه من خلال المداخل الأكثر تقليدية، بدون الاستثمار.[2]
ويمكن لاستخدام أدوات تحليل الكود أن تدعم هذا النشاط. وخاصة الأدوات التي تعمل في مجال بيئة التطوير المتكاملة IDE لأنها توفر تغذية راجعة مباشرة لمطوري تطابق معيار الكود
انظر أيضًا
المراجع
- ^ أ ب Kolawa، Adam (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. ص. 260. مؤرشف من الأصل في 2017-12-09.
{{استشهاد بكتاب}}: الوسيط غير المعروف|مؤلفين مشاركين=تم تجاهله يقترح استخدام|authors=(مساعدة) - ^ أ ب "Code review". Wikipedia (بEnglish). 4 Mar 2021. Archived from the original on 2021-11-08.
- ^ Jones، Capers؛ Christof، Ebert (أبريل 2009). "Embedded Software: Facts, Figures, and Future". IEEE Computer Society. مؤرشف من الأصل في 2019-12-13. اطلع عليه بتاريخ 2010-10-05.
- ^ Ganssle، Jack (فبراير 2010). "A Guide to Code Inspections" (PDF). The Ganssle Group. مؤرشف من الأصل (PDF) في 2018-12-15. اطلع عليه بتاريخ 2010-10-05.
- ^ Jones، Capers (يونيو 2008). "Measuring Defect Potentials and Defect Removal Efficiency". Crosstalk, The Journal of Defense Software Engineering. مؤرشف من الأصل في 2010-01-11. اطلع عليه بتاريخ 2010-10-05.
- Jason Cohen (2006). Best Kept Secrets of Peer Code Review (Modern Approach. Practical Advice.). Smartbearsoftware.com.
وصلات خارجية
- Security Code Review FAQs
- Security code review guidelines
- Lightweight Tool Support for Effective Code Reviews white paper
- Code Review Best Practices white paper by Adam Kolawa
- Best Practices for Peer Code Review white paper
- Code review case study
- "A Guide to Code Inspections" (Jack G. Ganssle)
- Article Four Ways to a Practical Code Review
- http://www.reviewboard.org/
- http://agilereview.org
