بازبینی کد (Code Review) در بسیاری از تیم‌ها به یک ایست بازرسی تبدیل شده است: نویسنده منتظر می‌ماند، بازبین با عجله نگاه می‌کند و سرانجام یک «تأیید» رد و بدل می‌شود تا کار به مرحلهٔ بعد برود. در چنین حالتی آیین برگزار می‌شود، اما آنچه قرار بود اتفاق بیفتد نمی‌افتد. بازبینی کد در واقع ارزان‌ترین نقطهٔ کشف اشتباه و یکی از کم‌هزینه‌ترین سازوکارهای انتقال دانش در تیم است؛ به شرطی که آن را بخشی از فرهنگ مهندسی بدانیم، نه یک مرحلهٔ اداری.
بازبینی کد سه کار می‌کند، نه یکی
وقتی از بازبینی حرف می‌زنیم، معمولاً فقط به یک خروجی فکر می‌کنیم: پیدا کردن باگ. اما هر بازبینی هم‌زمان سه کار انجام می‌دهد:
- کشف نقص: خطاهای منطقی، حالت‌های مرزی فراموش‌شده و مسیرهایی که آزمون خودکار پوشش نداده است.
- انتقال دانش: بازبین با کد جدید، تصمیم‌های تازه و محدودیت‌های واقعی سیستم آشنا می‌شود؛ چیزی که هیچ مستندی جای آن را نمی‌گیرد.
- تصمیم طراحی: بسیاری از بحث‌های مهم یک تیم دربارهٔ مرز ماژول‌ها، نام‌گذاری دامنه و جهت وابستگی‌ها، در دل همین بازبینی‌ها شکل می‌گیرد.
تیمی که بازبینی را فقط برای هدف اول تنظیم می‌کند، دو خروجی دیگر را از دست می‌دهد؛ و در عمل، همان هدف اول هم ضعیف می‌شود، چون بازبین‌ها خسته و بی‌انگیزه می‌شوند. اگر می‌خواهید بدانید فرهنگ مهندسی یک تیم در چه وضعی است، به جای مستندات معماری، به لحن کامنت‌های بازبینی نگاه کنید.
اندازهٔ تغییر، مهم‌ترین متغیری که نادیده می‌گیریم
کیفیت بازبینی بیش از هر چیز به اندازهٔ تغییر بستگی دارد، نه به دقت بازبین. یک درخواست ادغام (Pull Request) که ده‌ها فایل را جابه‌جا می‌کند، در عمل بازبینی نمی‌شود؛ مرور می‌شود، تأیید می‌شود و امیدواریم خوب باشد. در مقابل، تغییر کوچک و متمرکز را می‌توان واقعاً خواند، فهمید و درباره‌اش بحث کرد.
دو قاعدهٔ ساده در همین نقطه اثر می‌گذارد: نخست اینکه تغییر را تا حد امکان کوچک نگه دارید و بازآرایی (Refactoring) را از تغییر رفتار جدا کنید؛ دوم اینکه زمان انتظار بازبینی را کوتاه نگه دارید. درخواستی که دو روز روی میز می‌ماند، هم انگیزهٔ نویسنده را می‌گیرد و هم هزینهٔ ادغام را بالا می‌برد، چون در این فاصله شاخهٔ اصلی حرکت کرده است.
بازخوردی که کد را بهتر می‌کند، نه نویسنده را خسته
بیشتر ناراحتی‌های مربوط به بازبینی از آنجا می‌آید که نظرهای فنی و ترجیح‌های شخصی با یک لحن بیان می‌شوند. یک راه ساده، برچسب‌گذاری کامنت‌هاست:
- نقص: چیزی که اشتباه کار می‌کند یا در شرایط واقعی می‌شکند؛ این‌ها باید پیش از ادغام حل شوند.
- پرسش: «چرا این مسیر را انتخاب کردی؟» که اغلب به یک بحث طراحی سودمند تبدیل می‌شود.
- پیشنهاد: تغییر اختیاری با توضیح دلیل؛ نویسنده می‌تواند با استدلال ردش کند.
- سلیقه: قالب‌بندی و سبک شخصی که بهتر است به ابزار سپرده شود، نه به بحث انسانی.
نکتهٔ دوم، نوشتن دلیل است. جملهٔ «این را عوض کن» بدون توضیح، نویسنده را در موقعیت حدس زدن می‌گذارد و همان بحث را دو بار تکرار می‌کند. اگر بازخورد به چیدمان مسئولیت‌ها و مرزهای ماژول مربوط است، ارجاع به اصول SOLID در کد واقعی بحث را از سلیقه به معیار مشترک منتقل می‌کند. و اگر تصمیمی را عمداً به بعد موکول می‌کنید، آن را با صراحت به‌عنوان بدهی فنی ثبت کنید تا در آینده گم نشود.
مرز بازبینی انسانی و ابزار
بخش بزرگی از آنچه در بازبینی‌ها بحث می‌شود، اصلاً کار انسان نیست. قالب‌بندی، سبک کد، نام‌گذاری متغیرهای محلی، ترتیب ورودی‌ها و مواردی از این دست را باید تحلیل ایستا (Static Analysis) و آزمون خودکار (Automated Test) بگیرد. انسان باید جایی وقت بگذارد که ابزار نمی‌تواند قضاوت کند: انتخاب الگوریتم، مدل داده، مرزهای مسئولیت، حالت‌های شکست و تأثیر تغییر روی بخش‌های دیگر.
برای بخش امنیتی هم بهتر است به‌جای حافظه و سلیقهٔ بازبین، از یک فهرست مرجع استفاده شود؛ فهرست ریسک OWASP نقطهٔ شروع خوبی است تا در هر تغییر بررسی شود که ورودی اعتبارسنجی شده، دسترسی کنترل شده و دادهٔ حساس در گزارش‌ها لو نرود.
چک‌لیست کوتاه برای دو طرف
نویسنده
- توضیح کوتاه بنویسید: این تغییر چه مسئله‌ای را حل می‌کند و چه چیزهایی را عمداً حل نمی‌کند.
- تغییر را کوچک و تک‌هدف نگه دارید و بازآرایی را جدا کنید.
- پیش از ارسال، آزمون‌ها را اجرا کنید و خروجی ابزارها را ببینید؛ نگذارید بازبین کار ماشین را انجام دهد.
- کامنت را به‌عنوان گفت‌وگو ببینید، نه داوری دربارهٔ توانایی خودتان.
بازبین
- ابتدا بپرسید تغییر چه می‌کند؛ اگر پاسخ روشن نبود، همان‌جا سؤال کنید.
- روی مسیرهای اصلی و حالت‌های مرزی تمرکز کنید، نه روی سبک کد.
- هر کامنت را برچسب بزنید و دلیلش را بنویسید.
- تفاوت «باید» و «می‌شود» را روشن کنید تا نویسنده بداند چه چیزی مانع ادغام است.
جمع‌بندی
بازبینی کد وقتی مؤثر است که کوچک، سریع و محترمانه باشد و مرز روشنی با ابزار داشته باشد. هدف نهایی، تأیید گرفتن نیست؛ ساختن حافظهٔ مشترک تیم از تصمیم‌ها، خطرها و درس‌هایی است که در کد باقی می‌مانند. تیمی که بازبینی را جدی می‌گیرد، در واقع هر روز کمی دربارهٔ سیستمش یاد می‌گیرد — و این، پایدارترین شکل رشد مهندسی است.
