معرفی و تعریف
بازبینی کد یا «بازبینی کد» (Code Review) مهارت بررسی تغییرات نرمافزار پیش از ادغام آن‌ها با شاخه هدف پروژه است. بازبین کد بررسی میکند که تغییر پیشنهادی مسئله مورد نظر را به‌درستی حل کرده، با ساختار موجود سامانه سازگار است و ریسک غیرضروری برای کیفیت، امنیت یا نگهداری کد ایجاد نمی‌کند. این مهارت برای توسعه‌دهندگانی مناسب است که پیش‌تر با برنامه‌نویسی، کنترل نسخه و تست نرمافزار آشنا هستند.
چه مواردی را باید در بازبینی کد بررسی کرد؟
بازبین فقط به خطاهای نحوی یا سبک نوشتن کد توجه نمی‌کند. طراحی، صحت رفتار، پیچیدگی، تست‌ها، مدیریت خطا، نام‌گذاری، مستندات و اثر تغییر بر سایر بخش‌های سامانه نیز بخشی از بازبینی هستند.
در تغییرات حساس، موضوعاتی مانند کنترل دسترسی، داده‌های حساس، قراردادهای عمومی رابط برنامه‌نویسی کاربردی (API) و اثر تغییر بر معماری اهمیت بیشتری پیدا می‌کنند. اگر بررسی حوزه‌ای مانند امنیت، حریم خصوصی یا همزمانی خارج از تخصص بازبین باشد، لازم است فرد متخصص دیگری نیز در بازبینی مشارکت کند.
خروجی بازبینی کد معمولاً مجموعه‌ای از پرسش‌ها، نظرها و پیشنهادهای مشخص درباره تغییر است، نه بازنویسی کامل کد نویسنده. توسعهدهندگان، مهندسان ارشد، رهبران فنی و اعضای تیم‌های بک‌اند، فرانت‌اند، موبایل و زیرساخت از این مهارت استفاده می‌کنند. برای سرپرست فنی، بازبینی کد همچنین راهی برای حفظ سلامت پایگاه کد (Codebase)، انتقال دانش و کاهش ریسک تحویل است.
مسیر این صفحه حدود ۸۰ ساعت مطالعه و تمرین ساختاریافته را در نظر گرفته است. این عدد برآورد آموزشی همین مسیر است و زمان استانداردی برای کسب مهارت بازبینی کد محسوب نمی‌شود.
اهمیت و کاربردها
چرا این مهارت مهم است؟
تست‌های خودکار بخش مهمی از کنترل کیفیت نرمافزار هستند، اما همه مشکلات را تشخیص نمی‌دهند. ممکن است تغییر همه تست‌های موجود را با موفقیت پشت سر بگذارد، اما نیازمندی را اشتباه پیاده‌سازی کرده باشد، پیچیدگی غیرضروری ایجاد کند، ساختار سامانه را تضعیف کند یا مشکلی امنیتی وابسته به منطق کسب‌وکار داشته باشد. بازبینی کد (Code Review) فرصتی برای بررسی این مسائل پیش از ادغام تغییر فراهم میکند.
در گیت‌هاب (GitHub) و بیت‌باکت (Bitbucket)، معمولاً درخواست ادغام تغییر (Pull Request) و در گیت‌لب (GitLab)، درخواست ادغام (Merge Request) برای پیشنهاد، بررسی و گفت‌وگو درباره تغییرات استفاده می‌شود.
چگونه بازبینی کد را مؤثرتر کنیم؟
بازبینی کد می‌تواند به انتقال دانش نیز کمک کند. اعضای تیم با مشاهده تغییرات بخش‌های مختلف پایگاه کد (Codebase) و آشنایی با دلایل تصمیم‌ها، شناخت بیشتری از سامانه پیدا می‌کنند.
بااین‌حال، بازبینی کد نباید به ابزاری برای اعمال سلیقه شخصی یا مانعی دائمی در مسیر تحویل تبدیل شود. مواردی که می‌توان با قالب‌بند کد (Formatter)، تحلیل‌گر ایستا (Linter) و سایر ابزارهای خودکار بررسی کرد، بهتر است تا حد امکان خودکار شوند. به این ترتیب، زمان بازبین صرف تصمیم‌هایی می‌شود که به قضاوت انسانی نیاز دارند.
همچنین، تغییرات کوچک و متمرکز معمولاً آسان‌تر، سریع‌تر و دقیق‌تر بازبینی می‌شوند.
کاربردها
-
بررسی درخواست ادغام پیش از انتشار
Pull Request یا Merge Request را از نظر هدف، منطق، تست‌ها، اثر جانبی و آمادگی برای ادغام بررسی می‌کنید.
-
کشف ریسک‌های امنیتی در تغییرات
اعتبارسنجی ورودی، احراز هویت و مجوزدهی، افشای داده، تغییر وابستگی‌ها و اثر تغییر بر کنترل‌های امنیتی موجود را بررسی می‌کنید. برای تغییرات امنیتی پیچیده، بازبین متخصص نیز باید در فرایند حضور داشته باشد.
-
حفظ ساختار و مرزهای معماری
وابستگی‌های نامناسب، تکرار منطق، افزایش غیرضروری پیچیدگی و تغییراتی را که مرزهای معماری را تضعیف می‌کنند شناسایی می‌کنید.
-
بهبود و بررسی کیفیت تست‌ها
مشخص می‌کنید آیا تست‌ها رفتار مهم تغییر، حالت‌های مرزی و مسیرهای خطا را پوشش می‌دهند یا فقط جزئیات فعلی پیاده‌سازی را تکرار می‌کنند.
-
انتقال دانش در تیم
از گفت‌وگوی بازبینی برای توضیح تصمیم‌های فنی، قراردادهای کدبیس و دلیل استانداردهای تیم استفاده می‌کنید.
-
کنترل تغییرات پرریسک
برای Migration پایگاه داده، تغییر API عمومی، تغییر مجوزها یا بخش‌های حساس محصول، زمینه، تست، سازگاری و راهبرد بازیابی را دقیق‌تر بررسی می‌کنید.
ابزارهای مرتبط
پیش‌نیازها
شروع این مهارت با دانستن پیش‌نیازهای زیر هموارتر می‌شود.
- مهارت برنامه‌نویسی Programming
- مهارت کنترل نسخه Version Control
- مهارت تست نرمافزار Software Testing
- توانایی اجرای پروژه و خواندن تغییرات آن
- آشنایی مقدماتی با دامنه و نیازمندی تغییر مورد بررسی
مسیر یادگیری بازبینی کد
-
۱۰ ساعت
تغییرات نسخه‌بندی‌شده را بخوانید و دنبال کنید
در این گام، تفاوت میان commit، شاخه، درخواست ادغام و نسخه پایه را یاد بگیرید. در ادامه، چند تغییر کوچک را با Git بررسی کنید و بتوانید بگویید هر فایل چرا تغییر کرده است. تمرین کنید و تغییرات نامرتبط را از یک درخواست ادغام جدا تشخیص دهید.
-
۱۵ ساعت
معیارهای یک تغییر قابل پذیرش را بشناسید
پیش از بررسی جزئیات، هدف تغییر را بخوانید و مشخص کنید این تغییر قرار است چه مسئله‌ای را حل کند. سپس طراحی، صحت منطق، پیچیدگی، نام‌گذاری، مدیریت خطا، تکرار کد، مستندات و سازگاری با قراردادهای پروژه را بررسی کنید. میان موارد مسدودکننده، پیشنهادهای بهبود و ترجیح‌های شخصی تفاوت بگذارید. هدف بازبینی رسیدن به کد کامل و بی‌نقص نیست. تغییر باید سلامت کلی کدبیس را حفظ کند یا بهبود دهد و کیفیت آن برای ادغام کافی باشد.
-
۱۵ ساعت
تست و رفتار واقعی تغییر را ارزیابی کنید
تست‌های موجود و تست‌های اضافه‌شده همراه تغییر را بررسی کنید. ببینید آیا رفتار اصلی، حالت‌های مرزی، ورودی‌های نامعتبر و مسیرهای خطا پوشش داده شده‌اند.
نتیجه CI و سایر بررسی‌های خودکار را نیز بررسی کنید. اگر رفتار تغییر مبهم، پرریسک یا وابسته به محیط اجراست، کد را به‌صورت محلی اجرا کنید یا از نویسنده شواهد اجرای مناسب بخواهید. تلاش کنید تستی را که فقط پیاده‌سازی فعلی را تکرار میکند از تستی که رفتار مورد انتظار را بررسی میکند تشخیص دهید.
-
۱۵ ساعت
ریسک امنیتی و اثر معماری را بررسی کنید
تغییر را از نظر ورودی‌ها، کنترل دسترسی، افشای داده حساس، مدیریت خطا، وابستگی‌های جدید و تغییر قراردادهای عمومی بررسی کنید. برای تغییرات بزرگ‌تر، اثر آن بر مرز ماژول‌ها، جریان داده، عملکرد، سازگاری و امکان بازیابی را نیز در نظر بگیرید. در تغییرات امنیتی، ابتدا مشخص کنید آیا دانش کافی برای بررسی آن بخش دارید.
اگر موضوع شامل احراز هویت، مجوزدهی پیچیده، رمزنگاری، داده بسیار حساس یا سایر حوزه‌های تخصصی است، بازبین مناسب دیگری را نیز درگیر کنید. ابزارهای خودکار امنیتی میتوانند به شناسایی برخی مشکلات کمک کنند، اما جای بررسی منطق کسب‌وکار و قضاوت انسانی را نمی‌گیرند.
-
۱۰ ساعت
بازخورد دقیق و قابل اقدام بنویسید
هر نظر را تا حد امکان به بخش مشخصی از تغییر و دلیل فنی آن متصل کنید. به جای عبارت‌هایی مانند «این خوب نیست»، مسئله و پیامد آن را توضیح دهید. اگر راه‌حل مشخصی دارید آن را پیشنهاد کنید، اما در موضوعاتی که چند راه‌حل معتبر دارند ابتدا زمینه تصمیم نویسنده را بپرسید. بازخورد را درباره کد بنویسید، نه درباره توانایی فردی که آن را نوشته است.
اگر یک نظر مانع ادغام نیست، این موضوع را روشن کنید تا نویسنده بداند کدام تغییر الزامی و کدام پیشنهاد اختیاری یا آموزشی است. به تصمیم‌های خوب نیز اشاره کنید. بازبینی کد فقط برای پیدا کردن ایراد نیست.
-
۱۵ ساعت
بازبینی را در جریان تحویل تیمی تمرین کنید
برای چند درخواست ادغام واقعی یا نمونه، ابتدا خودتان بررسی کنید و سپس آن را با نظر بازبین باتجربه مقایسه کنید. GitHub، GitLab و Bitbucket نمونه‌هایی از پلتفرم‌هایی هستند که می‌توانید در آن‌ها تغییرات و نظرهای بازبینی را دنبال کنید. روی تغییرات کوچک و هدفمند تمرکز کنید، زمان پاسخ‌گویی را کوتاه نگه دارید و پس از اصلاح، فقط بخش‌های تغییرکرده را دوباره بررسی کنید.
پس از دست‌کم سه بازبینی کوچک، باید بتوانید هدف تغییر، ریسک‌های ضروری، موارد نیازمند تست و تفاوت میان نظر مسدودکننده و پیشنهاد را در نظرهای مستند ثبت کنید. سپس نظرهای خود را با بازخورد یک بازبین باتجربه مقایسه کنید و موارد جاافتاده را تحلیل کنید.
زمان تقریبی یادگیری
برآورد مجموع زمان آموزش، مطالعه و تمرین تا رسیدن به سطح کاربردی؛ بسته به پیش‌زمینه شما می‌تواند کمتر یا بیشتر باشد.
پروژه‌های تمرینی
موارد زیر تصویری کلی از این بخش برای این مهارت ارائه می‌کنند.
-
بازبینی یک درخواست ادغام کوچک
توضیح پروژه: یک تغییر کوچک از پروژه شخصی یا متن‌باز انتخاب کنید. هدف تغییر، ریسک‌های مهم، وضعیت تست و نظرهای الزامی یا پیشنهادی خود را ثبت کنید.
-
طراحی چک‌لیست بازبینی برای یک سرویس API
توضیح پروژه: چک‌لیستی کوتاه شامل اعتبارسنجی ورودی، مدیریت خطا، کنترل دسترسی، قرارداد پاسخ، تست حالت‌های مرزی و تغییرات سازگاری تهیه کنید و آن را روی یک تغییر واقعی اجرا کنید.
-
مقایسه دو بازبینی از یک تغییر
توضیح پروژه: ابتدا یک تغییر را مستقل بررسی کنید. سپس بازخورد توسعهدهنده باتجربهتر یا بازبین پروژه متن‌باز را بخوانید و مواردی را که ندیده‌اید تحلیل کنید.
-
بازبینی تغییر پرریسک داده
توضیح پروژه: یک Migration پایگاه داده یا تغییر قرارداد API را بررسی کنید و ریسک سازگاری، Migration، بازیابی و تست‌های لازم را به‌صورت نظرهای مشخص ثبت کنید.
پرسش‌های رایج درباره بازبینی کد
در این بخش، به تعدادی از پرسش‌های رایج درباره این مهارت پاسخ داده شده است.
آیا بازبینی کد فقط وظیفه توسعهدهنده ارشد است؟
خیر. توسعهدهندگان در سطحهای مختلف میتوانند Code Review انجام دهند. هر فرد باید در محدوده دانش و زمینهای که دارد بازخورد بدهد. برای مسائل تخصصی مانند معماری، امنیت یا همزمانی ممکن است بازبین باتجربهتر یا متخصص دیگری نیز لازم باشد.
در بازبینی کد، اولویت با سبک کدنویسی است یا منطق؟
صحت رفتار، طراحی، امنیت، تست و پیامد تغییر اهمیت بیشتری دارند. مواردی مانند قالب‌بندی و بسیاری از قواعد سبک بهتر است در صورت امکان با Formatter، Linter و ابزارهای خودکار بررسی شوند تا زمان بازبین صرف مسائل مهم‌تر شود.
چطور بازخوردی بدهم که شخصی یا تخریب‌کننده به نظر نرسد؟
درباره کد و پیامد آن صحبت کنید، نه نویسنده. دلیل فنی بازخورد را توضیح دهید و اگر راه‌حل مشخصی دارید آن را پیشنهاد کنید. در موضوعاتی که پاسخ قطعی ندارند، پرسیدن دلیل تصمیم یا مطرح‌کردن گزینه جایگزین معمولاً مفیدتر است.
آیا باید همه کد درخواست ادغام را خط‌به‌خط بخوانم؟
در حالت معمول باید همه کدی را که مسئول بازبینی آن هستید بخوانید و منطق آن را بفهمید. در تغییرات بزرگ ممکن است چند بازبین مسئول فایل‌ها یا جنبه‌های متفاوت باشند. در این حالت باید مشخص باشد هر فرد چه بخشی را بررسی کرده است. اگر اندازه تغییر مانع بازبینی دقیق می‌شود، بهتر است در صورت امکان از نویسنده بخواهید آن را به تغییرات کوچک‌تر و مستقل‌تر تقسیم کند.
اگر با تصمیم فنی نویسنده مخالف باشم، چه کنم؟
دلیل مخالفت، گزینه جایگزین و پیامد هر گزینه را توضیح دهید. اگر هر دو راه‌حل معتبر هستند، ترجیح شخصی را الزام معرفی نکنید. اگر موضوع به معماری یا استاندارد مشترک تیم مربوط است و در گفت‌وگو حل نمی‌شود، آن را به تصمیم فنی گسترده‌تر تیم منتقل کنید.
تفاوت بازبینی کد و تست نرمافزار چیست؟
تست رفتار نرمافزار را با اجرای سناریوها بررسی میکند. بازبینی کد علاوه بر تست، منطق، خوانایی، امنیت، طراحی و تناسب تغییر با نیازمندی را پیش از ادغام ارزیابی میکند. این دو مکمل هم هستند.
