بررسی کد در برخی تیم‌ها به تشریفاتی نیم‌ساعته تبدیل شده که تمام حرف‌هایش درباره جای کاما و نام متغیر است، و در برخی تیم‌های دیگر به کلوخی از تأییدهای بی‌مطالعه بدل شده که با یک کلیک ختم می‌شوند. دو وضعیت متضاد با یک علت مشترک: به پرسش «بررسی کد اصلاً برای چیست؟» پاسخ روشنی داده نشده است.
Code Review یعنی خواندن و ارزیابی تغییرات کد پیش از پیوستن به خط اصلی پروژه، توسط کسی جز نویسنده. معمولاً این کار در قالب درخواست ادغام (Pull Request) انجام می‌شود: نویسنده تغییرات را پیشنهاد می‌دهد، همکاران آن را می‌خوانند و درباره‌اش گفت‌وگو می‌کنند و در نهایت تغییر تأیید یا برای اصلاح برمی‌گردد.
در این مقاله همان پرسش را تحلیل می‌کنیم: چه چیزی را باید در بررسی کد گرفت، چه چیزی را نباید گرفت و یک فرآیند مؤثر چه ویژگی‌هایی دارد. در پایان، فهرستی عملی برای راه‌اندازی همین فرآیند در تیم خودتان خواهید داشت.
تحلیل پرسش؛ بررسی کد دنبال چیست؟
هدف نخست، کشف زودهنگام خطاست. خطایی که پیش از ادغام و روی میز همکار گرفته می‌شود، ارزان‌ترین خطای ممکن است؛ همان خطا اگر به دست کاربر برسد، هزینه گزارش‌گیری، عیب‌یابی و اعتماد ازدست‌رفته دارد. بررسی کد یک فیلتر انسانی برای همین کشف زودهنگام است.
هدف دوم، انتقال دانش است. وقتی دست‌کم یک نفر دیگر کد یک بخش را خوانده باشد، تیم با «دانش تک‌نفره» گروگان نمی‌شود؛ مرخصی یک توسعه‌دهنده یا ترک سازمان او، پروژه را فلج نمی‌کند. بررسی کد در عمل یک جلسه آموزشی پیوسته و کم‌هزینه است.
هدف سوم، هم‌راستایی با معماری و ثبات تصمیم‌هاست: آیا این تغییر با ساختار کلی می‌سازد؟ آیا مسئله مشابه قبلاً با روش دیگری حل شده است؟ این پرسش‌ها را نه کامپایلر جواب می‌دهد و نه ابزار قالب‌بندی؛ فقط چشم انسانِ آشنا به کل پروژه.
چه چیزهایی را باید بررسی کرد؟
- صحت منطق: آیا کد همان کاری را می‌کند که شرح کار می‌گوید؟ حالت‌های مرزی مثل ورودی خالی، مقدار صفر یا قطع شبکه پوشش داده شده‌اند؟
- امنیت: داده ورودی کاربر اعتبارسنجی می‌شود؟ دسترسی‌ها پیش از انجام عملیات حساس بررسی می‌شوند؟
- تست: آیا رفتار تازه با تست مناسب پشتیبانی می‌شود و تست‌های موجود را نمی‌شکند؟
- خوانایی و نام‌گذاری: آیا خواننده بعدی بدون توضیح شفاهی نویسنده می‌تواند کد را بفهمد؟
- سازگاری با معماری: آیا الگوی کد و محل قرارگیری‌اش با ساختار پروژه یکدست است؟
- عملکرد: آیا پرس‌وجو یا حلقه سنگینی اضافه شده که زیر بار واقعی گلوگاه شود؟
چه چیزهایی نباید موضوع بررسی شود؟
اینجا مرز فرآیند سالم با جزئی‌نگری (Micro-management) است. سلیقه شخصی درباره فاصله‌گذاری، جای آکولاد یا ترتیب فهرست کتابخانه‌ها موضوع گفت‌وگوی انسانی نیست؛ این‌ها را ابزار قالب‌بندی خودکار (Formatter) و تحلیل ایستا (Linter) بهتر و بی‌طرفتر انجام می‌دهند. اگر تیم در جلسات بررسی سر همین موارد بحث می‌کند، یعنی کار مکانیکی را به انسان سپرده است.
خط دوم، بازنویسی افکار نویسنده است. اگر راه‌حل درست کار می‌کند، تست دارد و با معماری می‌سازد، مخالفِ مجبورکردن نویسنده به «روش من» نیست؛ اینجاست که بررسی کد از ابزار کیفیت به ابزار قدرت تبدیل می‌شود و صداقت گفت‌وگوهای تیم را می‌خشکاند. پیشنهاد بدهید، اما با دلیل فنی و با پذیرش این احتمال که راه نویسنده هم درست است.
خط سوم، ارزیابی افراد در جلسه بررسی است. تعداد ایرادهای گرفته‌شده از یک نفر معیار ضعف او نیست؛ نشانه سلامت فرآیند است. محیطی که یادگیری در آن امن باشد، خطاها را زودتر آشکار می‌کند و دقیقاً همین آشکارشدن، هدف کار است.
| موضوع بررسی | مسئول پیشنهادی |
|---|---|
| قالب‌بندی، فاصله‌گذاری و سبک نگارش | ابزار خودکار |
| هشدارهای ایستا و خطاهای نگارشی نام‌ها | ابزار خودکار |
| صحت منطق و حالت‌های مرزی | انسان |
| امنیت و کنترل دسترسی | انسان |
| سازگاری با معماری پروژه | انسان |
| انتخاب رویکرد و طراحی راه‌حل | گفت‌وگوی انسانی با دلیل فنی |
مثال کاربردی؛ پلتفرم محتوایی و دو نوع بررسی
در یک پلتفرم محتوایی، توسعه‌دهنده‌ای قابلیت انتشار زمان‌بندی‌شده یادداشت‌ها را می‌سازد و درخواست ادغام می‌فرستد. بررسی‌کننده اول فقط می‌گوید نام متغیر کوتاه‌تر شود و فاصله خط آخر اصلاح گردد؛ هیچ چیز واقعی‌ای دستش را نمی‌گیرد و نویسنده هم چیزی یاد نمی‌گیرد.
بررسی‌کننده دوم که روی منطق تمرکز کرده، به نکته حساسی می‌رسد: زمان‌بندی بر اساس ساعت سرور انجام می‌شود، نه منطقه زمانی کاربر؛ نتیجه، یادداشت‌هایی است که ساعت‌ها دیر یا زود منتشر می‌شوند. همین یک مشاهده، هزینه کل فرآیند بررسی را جبران می‌کند. فاصله این دو نگاه، همان مرزی است که میان بررسی مؤثر و جزئی‌نگری کشیده می‌شود.
ویژگی‌های یک فرآیند بررسی مؤثر
- تغییرات کوچک: درخواست‌های چندصدخطی واقعاً خوانده نمی‌شوند؛ هرچه تغییر کوچک‌تر، بررسی عمیق‌تر و سریع‌تر.
- زمان پاسخ مشخص: منتظرماندن دو روزه برای بررسی، تیم را به ادغام بدون بررسی سوق می‌دهد؛ سقف زمانی ساده و شناخته‌شده‌ای برای پاسخ تعیین کنید.
- چک‌لیست مشترک: معیارها مکتوب باشند تا نظرها سلیقه‌ای نشود و نتیجه بررسی‌ها قابل پیش‌بینی باشد.
- لحن انسانی: نقد متعلق به کد است نه نویسنده؛ پیشنهاد همراه با دلیل، پرسش به‌جای اتهام.
- ابزار برای کارهای تکراری: قالب‌بندی، تحلیل ایستا و اجرای تست‌ها خودکار شوند تا وقت انسان برای منطق آزاد بماند.
- مالک مشخص هر بخش: برای کد هر حوزه بررسی‌کننده باتجربه‌ای تعیین شود و تصمیم‌های تکراری یک‌بار برای همیشه به سند تبدیل شوند.
خطاهای رایج
- تأیید بی‌مطالعه؛ تأییدی که فقط جلوی تعویق کار را می‌گیرد، از بررسی‌نکردن هم بدتر است چون ظاهر کنترل می‌سازد.
- درخواست‌های عظیمی که بررسی را عملاً ناممکن می‌کنند و هرچه در آن‌ها گم می‌شود بی‌صدا می‌ماند.
- تبدیل بررسی به میدان سلیقه‌های شخصی و بحث‌های بی‌پایان درباره جزئیات مکانیکی.
- اتکای کامل به بررسی برای کیفیت؛ بررسی مکمل تست است، نه جانشین آن.
نتیجه عملی؛ راه‌اندازی فرآیند در تیم خودتان
- قواعد مکانیکی را به ابزارها بسپارید و چک‌لیست انسانی را مکتوب و در دسترس همه قرار دهید.
- سقف اندازه درخواست ادغام و سقف زمان پاسخ را با تیم توافق کنید.
- برای هر بخش کد مالک فنی تعیین کنید؛ برای کدهای حساس مثل پرداخت و مدیریت دسترسی، دو بررسی‌کننده در نظر بگیرید.
- فضای گفت‌وگو را امن نگه دارید: نقد کد، نه نویسنده؛ و هیچ آمار فردی را به ابزار سنجش عملکرد تبدیل نکنید.
- هر چند ماه فرآیند را بازبینی کنید: چه چیزهایی گرفته می‌شود، چه چیزهایی می‌گریزد و کدام قاعده دیگر کمکی نمی‌کند؟
نکات کلیدی این مقاله
- هدف اصلی بررسی کد سه چیز است: کشف زودهنگام خطا، انتقال دانش و هم‌راستایی با معماری.
- موارد مکانیکی را به ابزارهای خودکار بسپارید و وقت انسان را برای منطق، امنیت و طراحی نگه دارید.
- مرز فرآیند سالم با جزئی‌نگری، همان مرز میان معیار مکتوب و سلیقه شخصی است.
- تغییرات کوچک، زمان پاسخ مشخص و لحن انسانی، سه ستون یک فرآیند پایدارند.
- بررسی کد مکمل تست و اتوماسیون است و جای هیچ‌کدام را نمی‌گیرد.
سوالات متداول
چند نفر باید یک درخواست ادغام را بررسی کنند؟
برای بیشتر تغییرات، یک بررسی‌کننده آشنا با آن حوزه کافی است؛ برای کدهای حساس مثل پرداخت و مدیریت دسترسی، دو نفر یا مالک بخش دیده می‌شود. تعداد بیشتر لزوماً کیفیت بیشتری نمی‌آورد، فقط زمان را زیاد می‌کند.
اگر نویسنده با نظر بررسی‌کننده موافق نباشد چه باید کرد؟
بحث روی معیار مکتوب و دلیل فنی انجام شود، نه روی سلسله‌مراتب و اعتبار افراد. اگر توافق حاصل نشد، تصمیم به مالک فنی آن بخش سپرده و نتیجه ثبت می‌شود تا برای بحث‌های بعدی مرجع باشد.
برای تغییرات کوچک هم فرآیند بررسی لازم است؟
بله، اما سبک: تغییر کوچک بررسی سریع‌تری می‌گیرد و همین خودش انگیزه کوچک‌ماندن تغییرات است. حذف کامل بررسی برای تغییرات کوچک، دریچه ورود استثناهای بی‌پایان می‌شود.
