درود دوستان 👋 توی قسمت قبل آداب انجام Code Review رو بررسی کردیم و با نکاتی آشنا شدیم که کمک کردن چطوری کدهای همکارانمون رو بررسی کنیم. نکتهٔ مقابل انجام کد ریویو اینه که چطوری اون رو از همکارانمون درخواست کنیم. اگه انتظار یک خروجی خوب داریم، می‌بایست هر دو طرف به صورت حرفه‌ای این کار رو انجام بدن. توی این قسمت می‌خوایم یاد بگیریم که چطوری درخواست Code Review داشته باشیم، طوری که افراد مشتاق به انجام این کار باشن و با جلوگیری از رفت و برگشت کارها، توی زمان و هزینه‌ها صرفه‌جویی بشه.

این پست از سری پست‌های «من مهندس نرم‌افزار هستم» هست که توی اونها با نکات فنی و غیر فنی که ما رو به یک مهندس نرم‌افزار خوب تبدیل می‌کنه آشنا می‌شیم. بریم که بحث اصلی این پست رو بررسی کنیم.

 

۱. PR هایی با اندازهٔ مناسب

نمیشه انتظار یک بررسی خوب داشت وقتی یک PR (Pull Request) که حجم تغییرات بالایی داره. یکی از وظایف بررسی‌کننده‌ها اینه که خط به خط کدها رو بررسی کنن. بنابراین بررسی چنین PR هایی هم زمان‌بر هست و هم نیاز به تمرکز و دقت بالایی داره. بهتره از ساختن PR های خیلی بزرگ خودداری و در صورت لزوم اونها رو به چند قسمت کوچیکتر تقسیم کنیم.

برای مثال پروژه‌ای شامل چند صفحه داشتیم که توی اونها از یک پلاگین برای نمایش اطلاعات در قالب یک جدول استفاده می‌شد. اون پلاگین یک آپدیت بزرگ منتشر کرد و ما هم می‌بایست این تغییرات رو توی صفحاتمون اعمال می‌کردیم. یک اتفاق که بررسی کدها رو سخت کرد این بود که توسعه‌دهنده توی همه صفحات تغییرات رو اعمال و اونها رو در قالب یک PR منتشر کرد و از تیم درخواست بررسی داشت. و در نتیجه کار بررسی سخت و طولانی شده بود و اون توسعه‌دهنده هم نمی‌تونست به ادامهٔ کارها بپردازه. راه حل بهتر این بود که تغییراتِ هر صفحه توی یک PR جدا قرار می‌گرفت، که در این شرایط بررسی کردن راحت‌تر و مؤثرتر انجام می‌شد.

 

۲. توضیحات مناسب توی PR

یک PR نباید صرفاً شامل کدها باشه. بلکه برای کوچیک‌ترین تغییری که انجام گرفته می‌بایست مستنداتی وجود داشته باشه، و اگه وجود نداشت توضیحاتی رو خودمون ارائه بدیم. ما از یک انسان درخواست بررسی کدها رو داریم و اون شخص احتمالاً اطلاعات کافی از دلیل تغییرات نداره.

یکی از راه‌کارها اینه که توی توضیحات PR تیکت یا Issue مربوطه رو لینک کنیم و یا توضیحات رو مستقیماً ارائه بدیم. اگه PR شامل تغییرات یا نکاتی هست که مستند نشده، حتماً می‌بایست به اونها اشاره کنیم تا بررسی‌کننده از علت اونها با خبر بشه.

 

۳. به اشتراک گذاشتن علت تصمیماتمون

همچنین خوبه که خواننده‌ها رو از علت تصمیماتمون با خبر کنیم. این کارها از رفت و برگشت‌ها جلوگیری می‌کنه و باعث میشه روند بررسی خیلی راحت‌تر و سریع‌تر انجام بشه. برای مثال جایی از کد از آبجکت به جای Enum استفاده کردیم. اگه پیش‌بینی می‌کنیم که این تصمیم دغدغه‌هایی رو برای افرادی که کدهای ما رو بررسی می‌کنن ایجاد می‌کنه، بهتره که همون خط کد رو انتخاب کنیم و توضیحاتی رو ارائه بدیم: