درود دوستان 👋 میخوایم ببینیم که چطوری و با چه تکنیکهایی میتونیم به شکل سازنده و مفید کدهای همکارانمون رو بررسی کنیم و به قول معروف Code Review انجام بدیم. این پست از سری پستهای «من مهندس نرمافزار هستم» هست که توی اونها نکات فنی و غیر فنی که ما رو به یک مهندس نرمافزار خوب تبدیل میکنه رو بررسی میکنیم.
بریم که نکات رو بررسی کنیم 🔥
۱. احترام، اصلِ اول کد ریویو
توی کد ریویو احترام حرف اول رو میزنه. احترام به خود، احترام به توسعهدهنده، احترام به پروژه و زحمات دیگران. هنگام کد ریویو ممکنه با کدهایی مواجه بشیم که از نظر ما عقلانی به نظر نمیاد. توی این شرایط هیچوقت نباید شخص کدنویس رو مخاطب قرار بدیم و مثلاً بگیم «چرا از تابع Generator استفاده کردی در صورتی که اینجا هیچ منفعتی نداره؟». این کار ممکنه فضای منفی و رقابتی رو بین ما و همکارمون به وجود بیاره که اتفاق خوشایندی نیست.
میتونیم با یک بیان دوستانهتر و سازندهتر احترام شخص کدنویس رو حفظ کنیم و فقط کدهای نوشتهشده رو مخاطب قرار بدیم و بگیم «تابع Generator توی این شرایط پیچیدگی رو افزایش میده و روی عملکرد برنامه تأثیر منفی میذاره. شاید یک روش سادهتر و بهینهتر استفاده از توابع عادی باشه».
۲. همیشه توضیح کافی بدیم
کد ریویو یکی از بهترین فرصتها برای یادگیری میتونه باشه که توی اون با نظرات و ایدههای دیگران آشنا میشیم. اگه شخصی از شما درخواست کد ریویو کرده، و اگه درخواست تغییراتی داریم، بجای اینکه صرفاً بگیم «از useState استفاده نکن»، میبایست با یک توضیح مختصر و سازنده درخواستمون رو اعلام کنیم تا علتش برای کدنویس مشخص باشه. مثلاً میتونیم بگیم «استفاده از useState توی این شرایط باعث رندرهای بیدلیل میشه کیفیت برنامه رو پایین میاره. بهتره که از useRef استفاده کنیم که تأثیری روی رندر شدن کامپوننت نداره».
وقتی توضیحاتی رو ارائه میدیم، شخص توسعهدهنده خیلی راحتتر میتونه دلیل پشت نکات شما رو متوجه بشه، از اون یاد بگیره و توی آینده از ایدهٔ شما استفاده کنه.
۳. نظراتمون رو با علامتهایی درجهبندی کنیم
برای مثال اگه درخواستمون خیلی جدی نیست و صرفاً یک توصیه و ترفند رو میخوایم به اشتراک بذاریم، میتونیم اون رو با برچسب «اختیاری» شروع کنیم و بگیم «اختیاری: خوبه که این قسمت رو منتقل کنی به یک فایل جدا». و یا از «صرفاً جهت اطلاع» برای مواردی که صرفاً میخوایم یک نکته انتقال بدیم: «صرفاً جهت اطلاع: این کد خیلی شبیه کدی هست که توی فایل retryHandler.ts داریم. خوبه که یه نگاهی بهش بندازی»
این روش کمک میکنه که به شخص توسعهدهنده منظورمون رو بهتر برسونیم. در غیر این صورت ممکنه شخص هر نظری رو به عنوان «درخواست تغییر» دریافت کنه و ناخواسته تغییراتی رو اعمال کنه که باعث هدر رفت وقت و انرژی و هزینه میشه.
۴. از یک کد خوب تعریف کنیم
کد ریویو فقط برای پیدا کردن اشتباهات و درخواست تغییر نیست. چقدر خوبه که اگه کدی رو میبینیم که خیلی تمیز نوشته شده و برای پروژه کمککننده هست به اونها اشاره و شخص رو تشویق کنیم. این کار باعث افزایش اعتماد به نفس میشه و فرآیند کد ریویو رو لذتبخش میکنه. مثلاً میتونیم بگیم «ریفکتور کردن این قسمت و منتقل کردن این توابع به یک فایل جدا چقدر کمککننده هست. این کار باعث میشه بهتر بتونیم کدها رو بررسی و تست کنیم. آفرین.»
۵. کدها رو تأیید کنیم و نظراتمون رو به اشتراک بذاریم
اگه فکر میکنیم که کدها خیلی خوب نوشته، اما میخواین نکاتی رو به اشتراک بذارین که اعمال شدن یا نشدن اونها زیاد اهمیتی نداره، میتونیم Pull Request رو حین اینکه نظراتمون رو هم بیان کردیم تأیید کنیم و دست کدنویس رو برای اعمال اونها باز بذاریم. این کار کمک میکنه از مسدود شدن کارها جلوگیری کنیم، مخصوصاً زمانی که حجم کارها زیاده یا با افرادی سر و کار داریم که از لحاظ منطقه زمانی با ما تفاوت دارن و میبایست از رفت و برگشت کارها جلوگیری کنیم.
مثلاً میتونیم بگیم «خیلی خوب شده. من PR رو تأیید میکنم اما یک سری نکاتی رو نوشتم. میتونی نگاهشون کنی و بعداً که فرصت داشتی اعمالشون کنی»
۶. تغییراتی که حتماً باید اعمال بشن
بعضی وقتها توسعهدهنده کدهایی رو نوشته که در مجموع خوب هستن، اما نکات ریز مثل کدنویسی تمیز و نامگذاری مناسب متغیرها رو رعایت نکرده. توی این شرایط نباید اجازه بدیم چنین کدهایی با بهانهٔ این که «بعداً درستش میکنم، بعداً تمیزکاری انجام میدم» تأیید و مرج بشن. چون معمولاً «بعداً» هیچوقت اتفاق نمیوفته. به محض اینکه کدها مرج میشن، توسعهدهنده مشغول به بقیه کارهاش میشه و اون نکات فراموش میشن.
میتونیم بگیم «قبل از مرج کردن کدها، میشه لطفاً کامنتها و کدهای اضافی رو برداری؟ این کار کمک میکنه خوانایی بالاتر بره برای کسانی که بعداً میخوان کدها رو بخونن».
۷. درخواست کوچیکتر کردن PR
گاهی اوقات با درخواست ریویو یک Pull Request (PR) مواجه میشیم که بیشتر از ۳۰۰ فایل توی اون تغییر کرده. توی این شرایط بررسی کردن کار خیلی سختی به حساب میاد. بهتره که از توسعهدهنده درخواست کنیم که اون رو به قسمتهای کوچیکتر تقسیم کنه، طوری که هر قسمت مربوط به یک کارایی خاصی باشه تا راحتتر بتونیم هم کدها و هم قابلیت پیادهسازی شده رو بررسی کنیم.
مثلاً میتونیم بگیم «توی این PR سه قابلیت متفاوت پیادهسازی شده که تست کردن اون سخت و زمانگیر میشه. امکانش هست هر کدوم رو توی یک PR مجزا قرار بدی؟»
۸. «راهنمایی کردن» رو به ارائه راه حل ترجیح بدیم
ما مجبور نیستیم که برای هر مشکلی که توی کدها میبینیم راه حل دقیق ارائه بدیم. گاهی اوقات میتونیم فقط به مشکل اشاره کنیم، تبعات اون رو به اشتراک بذاریم و یک راه حل کلی ارائه بدیم. این کار به توسعهدهنده این فرصت تحقیق و یادگیری میده و باعث بهبود مهارتهای حل مسئله میشه. مثلاً میتونیم بگیم که «این قسمت از کد باعث بلاک شدن صفحه میشه و بهتره از روشهای Async برای حل این مسئله استفاده کنیم»
۹. اول قسمتهای مهمتر
اگه با یک PR بزرگ مواجه هستیم بهتره اول قسمتهای اصلی و مهمتر اون رو بررسی کنیم. این کار بهمون کمک میکنه نیت و هدف تغییرات رو بهتر درک کنیم تا راحتتر و سریعتر بتونیم مشکلات اساسی رو پیدا کنیم و اونها رو گزارش بدیم. برای مثال میتونیم بگیم «من ریویو رو از فایل usePayment.ts شروع کردم چون فکر میکنم مهمترین قسمت این PR هست. توی این فایل چند تا مورد قابل توجه وجود داره که بهتره قبل از ادامهٔ بررسی PR به اونها پرداخته بشه، چون روی بقیه قسمتها تأثیر میذاره.»
۱۰. اگه مشغول کار مهمتری هستیم ...
درخواستهای کد ریویو هر چی زود تر باید انجام بشن تا از متوقف شدن حرکت تیم و پروژه جلوگیری بشه. اما گاهی اوقات مشغول کارهایی مثل دیباگ کردن یک قسمت هستیم که تمرکز بالایی احتیاج داره، نباید کارمون رو به این دلیل که ازمون درخواست کد ریویو شده متوقف کنیم. بهتره اون رو ادامه بدیم تا تمرکزمون حفظ بشه، و در اولین موقعیت مناسب به کد ریویو بپردازیم.
وقتی با یک درخواست کد ریویو مواجه هستیم اما در حال حاضر نیاز به تمرکز داریم، میتونیم بگیم «من PR شما رو دیدم. اما مشغول نوشتن یک کد هستم که حدود ۱ ساعت زمان میبره. بعد از اون PR شما رو نگاه میکنم». حفظ تمرکز توی مهندسی نرمافزار حائز اهمیت هست و از دست دادن اون هزینههایی مثل کاهش بهرهوری و هدر رفت زمان داره.
۱۱. وقتی توسعهدهنده با نکات ما مخالفت میکنه
کاملاً رایج هست که توسعهدهندهها گاهی اوقات با نظرات و درخواستهای ما موافق نباشن. توی چنین شرایطی اهمیت داره که نقطه نظرات شخص رو جویا بشیم. در واقع توسعهدهنده مدت زمان بیشتری رو نسبت به ما با کدهای خودش سر و کار داشته و پا فشاری کردن روی نقطه نظر خودمون نمیتونه رفتار سازندهای باشه. که توی این شرایط احترامها کمتر میشه و کار تیمی بیشتر روی رقابت با همتیمی ادامه پیدا میکنه.
مثلاً وقتی توسعهدهنده با نکته یا درخواست ما مخالفت کرده، خوبه که ابتدا دیدگاه شخص رو بررسی کنیم و اگه واقعاً حق با اون بود میتونیم بگیم «ممنون بابت شفافسازی که کردی. درسته، استفاده از این کامپوننت توی این قسمت از کد منطقیتر به نظر میاد.»
۱۲. پافشاری جایی که لازمه
یکی از مهمترین مسئولیتهایی که توی کد ریویو به عهده داریم اینه که از سلامت و کیفیت پروژه محافظت کنیم. بنابراین اگه با کدی مواجه بشیم که چنین معیارهایی رو نداره، خوبه که با لحن سازنده ولی شفاف نگرانیمون رو ابزار کنیم. مثلاً به نکاتی اشاره کردیم. اما توسعهدهنده با اونها مخالفت کرده. اما میدونیم که این کد صلاحیت مرج شدن رو نداره. توی چنین شرایطی میتونیم بگیم «من منظورت رو متوجه هستم که میگی تایم زیادی نداریم و باید تا قبل از Deadline پروژه رو برسونیم. اما این کد برخلاف استانداردهایی هست که برای پروژه در نظر گرفتیم و خوانایی و تست پروژه رو سختتر میکنه و برای آیندهٔ پروژه مناسب نیست.»
۱۳. کد ریویوی به موقع
وقتی از ما درخواست کد ریویو میشه، میبایست توی اولین فرصت و حداکثر تا یک روز کاری بررسی انجام و تأیید/برگشت داده بشه. این کار کمک میکنه که کار توسعهدهنده متوقف نشه و همچنین از Git Conflict هایی که به مرور زمان ایجاد میشن جلوگیری میکنه. دقت کنیم که توی تأیید یا رد PR نباید عجله کنیم. بلکه باید توی اولین وقت «بررسی کردن» رو شروع کنیم.
خب دوستان، این پست هم به پایان رسید. یادمون نره که رفتار و اعمال هر شخصی توی تیم تأثیر مستقیم روی اعضای دیگه میذاره و منفعت یا ضرری که هر عضو به تیم وارد میکنه زودتر از هر کسی به خودمون وارد میشه. پس ما به عنوان یک هم تیمی، چقدر خوبه که با رعایت چنین نکات ریزی به دنبال اثرات مثبت توی تیم باشیم. امیدوارم از نکاتی که بررسی کردیم استفاده کرده باشین. روزتون خوش 😉👋