Code Review در مهندسی نرم‌افزار، از آماده‌سازی تا ادغام
نویسنده: فرشاد روزبهانی
در بیشتر تیم‌ها، تغییر کد پیش از ادغام در شاخه اصلی باید توسط یک نفر دیگر هم دیده شود. به این کار Code Review یا بازبینی کد می‌گوییم. هدف فقط پیدا کردن باگ نیست. بازبینی خوب کمک می‌کند تغییر با نیاز محصول جور دربیاید، مشکل تازه‌ای به وجود نیاورد و کد برای نفر بعدی قابل فهم باشد.
بدون یک روند روشن، بازبینی گاهی به بحثی طولانی درباره سلیقه تبدیل می‌شود یا Pull Request چند روز منتظر می‌ماند. چند قاعده ساده کمک می‌کند کار زودتر جلو برود و چیزی از قلم نیفتد.
قبل از درخواست بازبینی
نویسنده هم در خوب پیش رفتن بازبینی نقش دارد. اگر تغییر مرتب و توضیحات کامل باشد، بررسی آن برای بقیه ساده‌تر می‌شود:
- تغییر را کوچک و متمرکز نگه دارید. بررسی Pull Requestهایی که چند موضوع بی‌ربط را با هم تغییر می‌دهند سخت‌تر است.
- در توضیحات بگویید چه مشکلی را حل می‌کنید و چرا این راه را انتخاب کرده‌اید. نوشتن فهرست فایل‌های تغییرکرده به تنهایی کافی نیست.
- رفتار مورد انتظار و راه بررسی آن را بنویسید. اگر رابط کاربری تغییر کرده، تصویر یا ویدئوی کوتاهی اضافه کنید.
- تغییرهای مربوط به قالب‌بندی را از تغییرهای اصلی جدا کنید تا بررسی کد راحت‌تر باشد.
- قبل از درخواست بازبینی، تست‌ها و بررسی‌های خودکار را اجرا کنید. اگر خطایی باقی مانده، دلیلش را توضیح دهید.
توضیحات خوب به سه پرسش جواب می‌دهد: چه مشکلی حل شده، چرا این راه‌حل انتخاب شده و برای بررسی آن باید چه مسیری را امتحان کرد. اگر تصمیم فنی مهمی جای دیگری گرفته شده، لینک یا خلاصه‌اش را هم بیاورید.
جریان پیشنهادی بازبینی
۱. اول هدف تغییر را بفهمید
قبل از خواندن خط‌به‌خط کد، توضیحات Pull Request و معیارهای پذیرش را بخوانید. اگر این تغییر بخشی از کار بزرگ‌تری است، ببینید دقیقا چه چیزی را پوشش می‌دهد. این کار کمک می‌کند بر اساس برداشت اشتباه نظر ندهید.
۲. یک نگاه کلی به تغییر بیندازید
فایل‌های تغییرکرده و ارتباطشان را ببینید. از خودتان بپرسید آیا راه‌حل با ساختار فعلی برنامه جور است و آیا فقط همان مسئله را حل می‌کند. اگر از همان ابتدا مسیر کلی کار روشن نباشد، بررسی جزئیات فایده چندانی ندارد.
۳. مسیرهای مهم را دنبال کنید
حالا ببینید داده از کجا می‌آید، چه تغییری می‌کند و در پایان چه اتفاقی می‌افتد. فقط حالت عادی را بررسی نکنید. بسته به نوع تغییر، ورودی اشتباه، مقدار خالی، خطای شبکه، سطح دسترسی کاربر و حالت‌های مرزی را هم در نظر بگیرید.
اگر ظاهر برنامه تغییر کرده، وضعیت بارگذاری و خطا، دسترس‌پذیری و نمایش در اندازه‌های مختلف صفحه را هم ببینید. در تغییرهای مربوط به داده یا API، اعتبارسنجی ورودی، دسترسی‌ها و سازگاری با بخش‌های دیگر برنامه مهم است.
۴. تست‌ها را بررسی کنید
ببینید تست‌ها چه چیزی را پوشش می‌دهند و آیا مسیر تازه یا حالت خطایی از قلم افتاده است. نتیجه CI را بخوانید و اگر لازم بود، تغییر را خودتان هم اجرا کنید. موفق بودن تست‌ها خبر خوبی است، اما به تنهایی ثابت نمی‌کند که تغییر نیاز محصول را درست برآورده کرده است.
۵. نظر دقیق و روشن بدهید
هر نظر را به بخش مشخصی از کد وصل کنید و بگویید مشکل کجاست. اگر راه‌حلی به ذهنتان می‌رسد، آن را هم پیشنهاد دهید. به جای «این خوب نیست» توضیح دهید چه چیزی ممکن است خراب شود و چه زمانی.
برچسب‌هایی مثل «مسدودکننده»، «نیازمند اصلاح» و «پیشنهاد» کمک می‌کنند نویسنده بفهمد کدام نظرها باید پیش از ادغام حل شوند. البته همه اعضای تیم باید از معنی این برچسب‌ها برداشت یکسانی داشته باشند. نظر سلیقه‌ای هم وقتی مفید است که روی خوانایی، قرارداد تیم یا نگه‌داری کد اثر بگذارد.
۶. تغییرها و گفت‌وگو را پیگیری کنید
نویسنده به نظرها پاسخ می‌دهد، اصلاح‌های لازم را انجام می‌دهد و اگر راه دیگری را انتخاب کرده، دلیلش را می‌گوید. بازبین هم تغییرها را دوباره می‌بیند تا مطمئن شود مسئله حل شده است. بستن یک گفت‌وگو یا گذاشتن واکنش به تنهایی کافی نیست. باید معلوم باشد هر مورد به کجا رسیده است.
۷. تأیید و ادغام
وقتی ایرادهای مهم حل شده‌اند، بررسی‌های خودکار موفق‌اند و تغییر با معیارهای پذیرش جور است، می‌توان Pull Request را تأیید و ادغام کرد. روش ادغام را طبق روال تیم پیش ببرید. اگر بعد از ادغام باید انتشار، مهاجرت داده یا بررسی خاصی انجام شود، مسئول آن را مشخص کنید.
بازبین چه چیزهایی را در اولویت بگذارد؟
اگر وقت کمی دارید، اول سراغ بخش‌های پرریسک بروید:
- درستی رفتار: آیا این تغییر مسئله را حل می‌کند و مسیرهای خطا را هم مدیریت می‌کند؟
- امنیت و حریم خصوصی: آیا مجوزها رعایت شده‌اند؟ داده حساس در log، پاسخ یا رابط کاربری افشا نمی‌شود؟
- سازگاری و پایداری: آیا مصرف‌کننده‌های قبلی، داده‌های موجود یا مسیر بازگشت تحت تأثیر قرار می‌گیرند؟
- سادگی و خوانایی: آیا دلیل این کد برای نفر بعدی قابل فهم است؟
- کارایی و آزمون‌پذیری: آیا هزینه‌ای غیرضروری ایجاد شده و رفتار مهم قابل بررسی است؟
قرار نیست در هر بازبینی همه چیز را با دقت یکسان بررسی کنیم. هرچه تغییر حساس‌تر باشد، باید وقت بیشتری برای بررسی آن بگذاریم. عوض کردن متن یک دکمه با تغییر سطح دسترسی یا مهاجرت پایگاه داده ریسک یکسانی ندارد.
بازخورد محترمانه، بخشی از کیفیت است
در بازبینی درباره کد حرف می‌زنیم، نه درباره توانایی نویسنده. لحن محترمانه هم گفت‌وگو را راحت‌تر می‌کند. مثلا پرسیدن «اگر این درخواست دوبار ارسال شود، ممکن است رکورد تکراری بسازیم؟» از گفتن «چرا این را این‌طوری نوشتی؟» دقیق‌تر است و راه بهتری برای ادامه بحث باز می‌کند.
نویسنده هم بهتر است بازخورد را بخشی از بهتر کردن تغییر بداند. اگر با پیشنهادی موافق نیست، دلیل فنی‌اش را توضیح دهد. گاهی این اختلاف‌ها نشان می‌دهند روال تیم روشن نیست. بهتر است تصمیم را جایی ثبت کنید تا در Pull Requestهای بعدی دوباره از اول درباره‌اش بحث نشود.
چند عادت که فرآیند را کند می‌کنند
- Pull Requestهای خیلی بزرگ: موضوع‌های جدا را در تغییرهای جداگانه بفرستید.
- منتظر گذاشتن نویسنده: زمان معمول بازبینی را در تیم مشخص کنید. اگر کاری فوری است، دلیلش را بگویید.
- نظرهای مبهم: هر نظر باید یک مسئله روشن را مطرح کند تا نویسنده بداند چه چیزی را تغییر دهد.
- بحث درباره سلیقه: قالب‌بندی و قانون‌های ثابت تیم را به ابزارها بسپارید تا وقت بازبینی صرف منطق کد شود.
- تأیید بدون بررسی: پیش از تأیید، تغییر را واقعا بخوانید. کلیک روی دکمه جای بازبینی را نمی‌گیرد.
چک‌لیست کوتاه
قبل از ثبت Pull Request، توضیحش را کامل کنید و تست‌ها را اجرا کنید. هنگام بازبینی، هدف تغییر، مسیرهای اصلی و خطا، امنیت و نتیجه تست‌ها را متناسب با میزان حساسیت کار بررسی کنید. در پایان هم مطمئن شوید ایرادهای مهم حل شده‌اند و همه می‌دانند بعد از ادغام چه کاری باید انجام شود.
Code Review مسابقه‌ای برای پیدا کردن بیشترین تعداد ایراد نیست. فرصتی است تا یک نفر دیگر تغییر را ببیند و کمک کند کد درست‌تر و روشن‌تر وارد برنامه شود.