درود دوستان 👋 توی قسمت قبل آداب انجام Code Review رو بررسی کردیم و با نکاتی آشنا شدیم که کمک کردن چطوری کدهای همکارانمون رو بررسی کنیم. نکتهٔ مقابل انجام کد ریویو اینه که چطوری اون رو از همکارانمون درخواست کنیم. اگه انتظار یک خروجی خوب داریم، میبایست هر دو طرف به صورت حرفهای این کار رو انجام بدن. توی این قسمت میخوایم یاد بگیریم که چطوری درخواست Code Review داشته باشیم، طوری که افراد مشتاق به انجام این کار باشن و با جلوگیری از رفت و برگشت کارها، توی زمان و هزینهها صرفهجویی بشه.
این پست از سری پستهای «من مهندس نرمافزار هستم» هست که توی اونها با نکات فنی و غیر فنی که ما رو به یک مهندس نرمافزار خوب تبدیل میکنه آشنا میشیم. بریم که بحث اصلی این پست رو بررسی کنیم.
۱. PR هایی با اندازهٔ مناسب
نمیشه انتظار یک بررسی خوب داشت وقتی یک PR (Pull Request) که حجم تغییرات بالایی داره. یکی از وظایف بررسیکنندهها اینه که خط به خط کدها رو بررسی کنن. بنابراین بررسی چنین PR هایی هم زمانبر هست و هم نیاز به تمرکز و دقت بالایی داره. بهتره از ساختن PR های خیلی بزرگ خودداری و در صورت لزوم اونها رو به چند قسمت کوچیکتر تقسیم کنیم.
برای مثال پروژهای شامل چند صفحه داشتیم که توی اونها از یک پلاگین برای نمایش اطلاعات در قالب یک جدول استفاده میشد. اون پلاگین یک آپدیت بزرگ منتشر کرد و ما هم میبایست این تغییرات رو توی صفحاتمون اعمال میکردیم. یک اتفاق که بررسی کدها رو سخت کرد این بود که توسعهدهنده توی همه صفحات تغییرات رو اعمال و اونها رو در قالب یک PR منتشر کرد و از تیم درخواست بررسی داشت. و در نتیجه کار بررسی سخت و طولانی شده بود و اون توسعهدهنده هم نمیتونست به ادامهٔ کارها بپردازه. راه حل بهتر این بود که تغییراتِ هر صفحه توی یک PR جدا قرار میگرفت، که در این شرایط بررسی کردن راحتتر و مؤثرتر انجام میشد.
۲. توضیحات مناسب توی PR
یک PR نباید صرفاً شامل کدها باشه. بلکه برای کوچیکترین تغییری که انجام گرفته میبایست مستنداتی وجود داشته باشه، و اگه وجود نداشت توضیحاتی رو خودمون ارائه بدیم. ما از یک انسان درخواست بررسی کدها رو داریم و اون شخص احتمالاً اطلاعات کافی از دلیل تغییرات نداره.
یکی از راهکارها اینه که توی توضیحات PR تیکت یا Issue مربوطه رو لینک کنیم و یا توضیحات رو مستقیماً ارائه بدیم. اگه PR شامل تغییرات یا نکاتی هست که مستند نشده، حتماً میبایست به اونها اشاره کنیم تا بررسیکننده از علت اونها با خبر بشه.
۳. به اشتراک گذاشتن علت تصمیماتمون
همچنین خوبه که خوانندهها رو از علت تصمیماتمون با خبر کنیم. این کارها از رفت و برگشتها جلوگیری میکنه و باعث میشه روند بررسی خیلی راحتتر و سریعتر انجام بشه. برای مثال جایی از کد از آبجکت به جای Enum استفاده کردیم. اگه پیشبینی میکنیم که این تصمیم دغدغههایی رو برای افرادی که کدهای ما رو بررسی میکنن ایجاد میکنه، بهتره که همون خط کد رو انتخاب کنیم و توضیحاتی رو ارائه بدیم:
۴. کارهای اضافی انجام ندیم
گاهی اوقات هنگام کدنویسی پیش میاد که حس کنیم قسمتی از کد فعلی نیاز به ریفکتور داره. برای مثال تغییر نام یک متغیر یا تابع و بهبود کارایی یک قطعه کد که ارتباطی با وظیفهای که مشغول اون هستیم نداره. توی این شرایط نباید چنین کدهایی رو دستکاری کنیم. همونطور که توی قسمت قبل بررسی کردیم، یک PR باید فقط شامل کدهای مرتبط باشه و از انجام فعالیتهای بیربط توی PR خودداری بشه.
اگه قصد تغییر یا بهبود قسمتی از کد رو داریم، بهتره که اون رو قالب یک فعالیت و یک PR مجزا انجام بدیم. این کار به انسجام PR کمک میکنه و شخصی که کدهای ما رو بررسی میکنه میتونه با تمرکز و سرعت بیشتری این کار رو انجام بده.
۵. انتخاب شخص مناسب برای Review
گاهی اوقات شخصی رو برای Review انتخاب میکنیم که با فایلهایی که تغییر دادیم و ویژگی که اضافه کردیم کمترین آشنایی رو داره. توی این شرایط قطعاً کد ریویو نه تنها طولانیتر میشه و وقت طرفین گرفته میشه، بلکه ممکنه برای شخص بررسیکننده گیجکننده باشه و نظراتی رو ارائه بده که ارزش بالایی نداشته باشه.
اگه با GitHub کار کرده باشید، معمولاً هنگام ساختن PR و انتخاب Reviewer ها، گیتهاب اشخاصی که جدیداً روی فایلهایی که تغییر دادید کار کردند رو نشون میده و پیشنهاد میکنه.
همچنین انتخاب چندین بررسیکننده برای یک PR کار مناسبی به حساب نمیاد. توی این شرایط ممکنه هر شخص تمام و کمال بررسی رو انجام نده و اون رو بندازهٔ روی دوش دیگری؛ که در نتیجه باعث هدر رفت زمان و انرژی و افزایش سردرگمی توسعهدهنده و بررسیکنندهها میشه.
خب دوستان، امیدوارم از نکاتی که بررسی کردیم استفاده کرده باشین. یادمون باشه که فقط مهارتهای فنی و Hard Skill نیست که ما رو به یک مهندس نرمافزار با ارزش تبدیل میکنه. بلکه به نظر من توجه به چنین مهارتهای ارتباطی و به قول معروف Soft skills حداقل ۵۰٪ موفقیت یک مهندس نرمافزار تعیین میکنن. روزتون خوش 👋🌹