بازبینی کد

بندانگشتی|220x124px | چپ | مهندسان نرم‌افزار (یا همان برنامه‌نویسان) در حال بازبینی یک برنامه
**بازبینی کد** () (که گاهی به آن بازبینی همتا گفته می‌شود) یک فعالیت تضمین کیفیت نرم‌افزار است که در آن یک یا چند نفر کد منبع یک برنامه رایانه‌ای را پس از پیاده‌سازی یا در حین فرایند توسعه بررسی می‌کنند. افرادی که عمل بررسی را انجام می‌دهند (به جز نویسنده کد)، «بازبین» (Reviewer) نامیده می‌شوند. حداقل یک بازبین نباید نویسنده خودِ کد باشد.

بازبینی کد با سایر تکنیک‌های تضمین کیفیت نرم‌افزار مانند تحلیل ایستای کد، خود-بررسی، آزمون (تست) و برنامه‌نویسی دوتایی تفاوت دارد. تحلیل ایستا عمدتاً بر ابزارهای خودکار متکی است، خود-بررسی تنها شامل نویسنده کد می‌شود، آزمون نیازمند اجرای کد است و برنامه‌نویسی دوتایی به جای اینکه یک مرحله جداگانه باشد، به طور مداوم در طول توسعه انجام می‌شود.

## هدف
اگرچه کشف مستقیم مشکلات کیفی اغلب هدف اصلی است، بازبینی‌های کد معمولاً برای دستیابی به ترکیبی از اهداف زیر انجام می‌شوند:

* *بهبود کیفیت کد*بهبود کیفیت داخلی کد و قابلیت نگهداری از طریق خوانایی بهتر، یکنواختی و قابلیت درک.
* *تشخیص [[باگ نرم‌افزاری|نقص‌ها]]*بهبود کیفیت در جنبه‌های خارجی، به ویژه صحت عملکرد، و همچنین یافتن مسائلی مانند مشکلات عملکردی (Performance)، آسیب‌پذیری‌های امنیتی و بدافزارهای تزریق شده.
* *یادگیری/انتقال دانش*اشتراک‌گذاری دانشِ پایگاه کد (Codebase)، رویکردهای حل مسئله و انتظارات کیفی، هم برای بازبینان و هم برای نویسنده.
* *افزایش حس مسئولیت متقابل*افزایش حس مالکیت کد جمعی و همبستگی.
* *یافتن راه‌حل‌های بهتر*تولید ایده‌هایی برای راه‌حل‌های جدید و بهتر و ایده‌هایی فراتر از کد خاصِ در دست بررسی.
* *تطابق با دستورالعمل‌های تضمین کیفیت (QA) و استانداردهای ISO/IEC*بازبینی کد در برخی زمینه‌ها، مانند نرم‌افزارهای ترافیک هوایی و نرم‌افزارهای ایمنی-حیاتی اجباری است.

## انواع بازبینی

انواع مختلفی از فرایندهای بازبینی کد وجود دارد و انواع اضافی در استاندارد IEEE 1028 مشخص شده‌اند.

* بازبینی‌های مدیریتی
* بازبینی‌های فنی
* بازرسی‌ها (Inspections)
* مرورهای گام‌به‌گام (Walk-throughs)
* ممیزی‌ها (Audits)

### بازرسی (رسمی)

اولین فرایند بازبینی کد که به تفصیل مطالعه و توصیف شد، توسط مخترع آن، مایکل فاگان، «بازرسی» (Inspection) نامیده شد. بازرسی فاگان یک فرایند رسمی است که شامل اجرای دقیق و با جزئیات با چندین شرکت‌کننده و چندین فاز است. در بازبینی‌های رسمی کد، توسعه‌دهندگان نرم‌افزار در مجموعه‌ای از جلسات شرکت می‌کنند تا کد را خط به خط، اغلب با استفاده از نسخه‌های چاپ شده، بررسی کنند. تحقیقات نشان داده است که بازرسی‌های رسمی بسیار دقیق و در شناسایی نقص‌ها بسیار مؤثر هستند.

### بازبینی منظم مبتنی بر تغییر (مرورهای گام‌به‌گام)
تیم‌های توسعه نرم‌افزار معمولاً یک فرایند بازبینی سبک‌تر را اتخاذ می‌کنند که در آن دامنه هر بازبینی مربوط به تغییرات در پایگاه کد (Codebase) مطابق با یک تیکت، داستان کاربر (User story)، کامیت (Commit) یا واحد دیگری از کار است. علاوه بر این، قوانین یا قراردادهایی وجود دارد که وظیفه بازبینی را از طریق روش‌هایی مانند بازبینی اجباری تمام تیکت‌ها، معمولاً به عنوان بخشی از یک پول ریکوئست (درخواست ادغام)، به جای برنامه‌ریزی صریح برای هر بازبینی، در جریان کاری توسعه ادغام می‌کند. چنین فرایندی «بازبینی کد منظم و مبتنی بر تغییر» نامیده می‌شود. تغییرات زیادی از این فرایند پایه وجود دارد.

یک نظرسنجی در سال ۲۰۱۷ از ۲۴۰ تیم توسعه نشان داد که ۹۰٪ از تیم‌هایی که از بازبینی کد استفاده می‌کردند، از یک فرایند مبتنی بر تغییر پیروی می‌کردند و ۶۰٪ به طور خاص از بازبینی منظم مبتنی بر تغییر استفاده می‌کردند.
شرکت‌های بزرگ نرم‌افزاری که شناخته شده است از بازبینی کد مبتنی بر تغییر استفاده می‌کنند شامل مایکروسافت،
گوگل،
و فیس‌بوک هستند.

## کارایی و اثربخشی

تحقیقات در حال انجام توسط کیپرز جونز (Capers Jones) با تجزیه و تحلیل بیش از ۱۲٬۰۰۰ پروژه توسعه نرم‌افزار نشان داد که بازرسی‌های رسمی نرخ کشف نقص نهفته ۶۰ تا ۶۵ درصد داشتند، در حالی که بازرسی‌های غیررسمی کمتر از ۵۰ درصد نقص‌ها را شناسایی کردند. نرخ کشف نقص نهفته برای اکثر اشکال آزمون (تست) حدود ۳۰ درصد است. یک مطالعه موردی بازبینی کد که در کتاب «بهترین اسرار حفظ شده بازبینی همتای کد» (Best Kept Secrets of Peer Code Review) منتشر شد، مطالعه کیپرز جونز را نقض کرد و دریافت که بازبینی‌های سبک (Lightweight) می‌توانند به اندازه بازبینی‌های رسمی باگ پیدا کنند، در حالی که سریع‌تر و کم‌هزینه‌تر هستند.

مطالعات نشان می‌دهد که تا ۷۵٪ از نظرات در بازبینی کد به جای عملکرد، بر قابلیت تکامل و قابلیت نگهداری نرم‌افزار تأثیر می‌گذارد، که نشان می‌دهد بازبینی کد ابزاری عالی برای شرکت‌های نرم‌افزاری با چرخه‌های عمر طولانی محصول یا سیستم است. بنابراین، کمتر از ۱۵٪ از مسائل مورد بحث در بازبینی‌های کد مستقیماً به باگ‌ها مربوط می‌شود.

### دستورالعمل‌ها

تحقیقات نشان می‌دهد که اثربخشی بازبینی با سرعت بازبینی همبستگی دارد. نرخ‌های بهینه بازبینی کد بین ۲۰۰ تا ۴۰۰ خط کد در ساعت متغیر است. بازرسی و بازبینی بیش از چند صد خط کد در ساعت برای نرم‌افزارهای حیاتی (مانند نرم‌افزار تعبیه‌شده ایمنی-حیاتی) ممکن است برای یافتن خطاها بیش از حد سریع باشد.

### ابزارهای پشتیبانی

ابزارهای تحلیل ایستای کد با بررسی خودکار کد منبع برای آسیب‌پذیری‌های شناخته شده و الگوهای نقص، به ویژه برای بخش‌های بزرگی از کد، به بازبینان کمک می‌کنند. یک مطالعه در سال ۲۰۱۲ توسط VDC Research گزارش می‌دهد که ۱۷٫۶٪ از مهندسان نرم‌افزار تعبیه‌شده که مورد نظرسنجی قرار گرفتند، در حال حاضر از ابزارهای خودکار برای پشتیبانی از بازبینی همتای کد استفاده می‌کنند و ۲۳٫۷٪ قصد دارند در عرض دو سال از آنها استفاده کنند.

## جستارهای وابسته

* بازبینی نرم‌افزار
* کیفیت نرم‌افزار

## پیوندهای بیرونی

* پنج ضدالگوی بازبینی کد (انگلیسی)
* مجله جاوا، بهترین‌های ۲۰۲۰ (انگلیسی)

## منابع

رده:کد منبع
رده:داوری همتا