مقدمه
در درس قبل آموختیم که Pull Request قلب همکاری تیمی در گیت‌هاب است. اکنون می‌خواهیم به
مهم‌ترین فرآیندی که در دل یک Pull Request اتفاق می‌افتد بپردازیم: بازبینی کد
(Code Review). بازبینی کد فرآیندی است که در آن، توسعه‌دهندگان کد یکدیگر را به صورت
نظام‌مند بررسی می‌کنند تا از کیفیت، صحت و خوانایی آن اطمینان حاصل کنند.
این فرآیند یک سرمایه‌گذاری حیاتی در سلامت بلندمدت هر پروژه نرم‌افزاری است. تیمی که فرهنگ بازبینی
کد را جدی می‌گیرد، نه تنها نرم‌افزار بهتری تولید می‌کند، بلکه اعضای آن نیز سریع‌تر رشد کرده و
دانش در سراسر تیم به اشتراک گذاشته می‌شود.
اهداف اصلی بازبینی کد چیست؟
بازبینی کد اهداف متعددی را دنبال می‌کند که همگی در نهایت به یک محصول باکیفیت‌تر منجر می‌شوند.
- افزایش کیفیت کد: این واضح‌ترین هدف است. چشمان بیشتر، باگ‌های بیشتری را پیدا می‌کنند.
بازبین‌ها می‌توانند مشکلات منطقی، موارد مرزی (edge cases) فراموش‌شده، یا
پیاده‌سازی‌های ناکارآمد را قبل از اینکه به دست کاربر برسند، شناسایی کنند.
- حفظ ثبات و یکپارچگی کدبیس: هر تیمی سبک کدنویسی (Coding Style) و الگوهای معماری
خاص خود را دارد. بازبینی کد تضمین می‌کند که کدهای جدید با این استانداردها مطابقت داشته و
کدبیس پروژه در طول زمان یکپارچه و خوانا باقی بماند.
- اشتراک‌گذاری دانش: بازبینی کد یک ابزار آموزشی فوق‌العاده است. اعضای تیم با دیدن کد
یکدیگر، با بخش‌های مختلف پروژه و تکنیک‌های جدید برنامه‌نویسی آشنا می‌شوند. این فرآیند به طور
طبیعی به همه کمک می‌کند تا به توسعه‌دهندگان بهتری تبدیل شوند.
- مالکیت جمعی کد (Collective Code Ownership): وقتی همه اعضای تیم کد یکدیگر را بازبینی
می‌کنند، احساس مسئولیت مشترک نسبت به کل پروژه تقویت می‌شود. این امر از وضعیتی که در آن فقط
یک نفر از یک ماژول خاص سر در می‌آورد (و در صورت غیبت او پروژه به مشکل می‌خورد) جلوگیری
می‌کند.
نقش بازبین (Reviewer)
اگر به عنوان بازبین به یک Pull Request اضافه شدید، مسئولیت شما فقط پیدا کردن باگ نیست.
شما باید به تصویر بزرگتر نگاه کنید. در اینجا یک چک‌لیست از مواردی که یک بازبین خوب باید بررسی
کند، آورده شده است:
- آیا کد کار می‌کند؟ آیا منطق کد درست است و هدف Pull Request را برآورده می‌کند؟
- آیا کد خوانا و قابل نگهداری است؟ آیا نام متغیرها و توابع گویا هستند؟ آیا کد بیش از حد
پیچیده نیست؟ آیا یک توسعه‌دهنده جدید می‌تواند به راحتی آن را بفهمد؟
- آیا کد امن است؟ آیا ملاحظات امنیتی (مانند اعتبارسنجی ورودی‌ها) در نظر گرفته شده است؟
- آیا تست‌ها کافی هستند؟ آیا کد جدید دارای تست‌های واحد (Unit Tests) مناسبی است
که عملکرد آن را پوشش دهد؟
- آیا با معماری پروژه سازگار است؟ آیا این تغییر، الگوها و ساختار کلی پروژه را دنبال
می‌کند؟
بهترین روش‌ها برای یک بازبینی کد سازنده
نحوه ارائه بازخورد به اندازه خود بازخورد اهمیت دارد. هدف، بهبود کد است، نه انتقاد از نویسنده.
برای نویسنده (Author)
- قبل از درخواست بازبینی، کد خود را بازبینی کنید: Pull Request خود را طوری آماده
کنید که انگار خودتان بازبین آن هستید. اشتباهات تایپی و مشکلات واضح را برطرف کنید.
- زمینه را فراهم کنید: در توضیحات PR، به وضوح توضیح دهید که این تغییر «چه کاری»
انجام می‌دهد و «چرا» این کار لازم است. به Issue مربوطه لینک دهید.
- بازخورد را شخصی نگیرید: به یاد داشته باشید که نقدها متوجه کد شماست، نه شخصیت شما. با
ذهنی باز به دنبال یادگیری از بازخوردها باشید.
برای بازبین (Reviewer)
- سازنده و محترمانه باشید: به جای دستور دادن («این را عوض کن»)، سوال بپرسید («نظرت در
مورد استفاده از این الگو چیست؟»). لحن شما باید حمایت‌گرانه باشد.
- بازخورد خود را مشخص و قابل اجرا ارائه دهید: به جای گفتن «این کد پیچیده است»، بگویید
«می‌توانیم این تابع را به دو تابع کوچکتر تقسیم کنیم تا خوانایی آن بهتر شود؟».
- بین موارد ضروری و سلیقه‌ای تمایز قائل شوید: اگر یک پیشنهاد فقط بر اساس سلیقه شخصی
شماست، آن را با پیشوندهایی مانند Nitpick: (به معنی وسواس بی‌مورد) مشخص کنید تا
نویسنده بداند که اعمال آن اختیاری است.
- کار خوب را تحسین کنید: بازبینی کد فقط برای پیدا کردن مشکل نیست. اگر از یک راه‌حل
هوشمندانه یا یک قطعه کد تمیز خوشتان آمد، حتماً آن را ذکر کنید.