چطور کد دیگران رو بررسی کنیم؟ راهنمایی برای code review

در دنیای برنامه نویسی، بررسی کد سایر اعضای تیم یکی از وظایف مهم برنامه نویس‌های ارشد تیم هست. وقتی شما یک pull request ارسال می‌کنید، سایر برنامه نویسان کد شما رو بررسی می‌کنن، در موردش نظراتی رو می‌نویسن و پس از اینکه اصلاحات لازم انجام شد، اون رو با برنچ مورد نظر merge می‌کنن.

ممکن هست که خود شما در موقعیتی قرار گرفته باشید که وظیفه دارین کد سایر افراد تیم رو بررسی کنید. همه‌ی ما در مرحله‌ی اول سعی می‌کنیم بر طبق اصولی که قبلا در مورد کد ما نظر می‌دادن پیش بریم و بر اساس همون، کد سایر برنامه نویس‌ها رو بررسی کنیم. همیشه یادتون باشه شما با review فقط قصد دارید کد اون‌ها (در صورت امکان) بهتر کنید و به هیچ وجه قصد توهین و حمله به کد دیگران رو ندارید! پس با چنین دیدگاهی پیش نرید. ما حتی در این مرحله می‌تونیم خیلی موارد و ترفندهای جالبی از کد هم تیمی‌هامون یاد بگیریم.

هدف از اینکار چیه؟ ما باید مطمئن بشیم که تغییرات جدید آسیبی به سایر بخش‌های برنامه وارد نمی‌کنه و همچنین طبق قوائد کد نویسی که در تیم وجود داره نوشته شده باشه.

در ادامه در مورد اصولی صحبت می‌کنیم که به شما کمک می‌کنه تا بهتر بتونید کد دیگران رو بررسی کنید.

نکات اساسی

هر pull request یک هدفی داره. قبل از اینکه کد رو بخونید، حتما به عنوان pull request توجه کنید. این کار باعث میشه تا دید کامل تری در هنگام code review داشته باشین. همچنین به اسم فایل‌هایی هم که تغییر کردن توجه کنید تا بدونین چه بخش‌هایی از پروژه قرار هست بروز بشن. در ادامه مطمئن بشید که فایل‌هایی که قرار هست تغییر کنن، بخشی از کاری هست که بر اساس عنوان pull request بیان شده.

پس از این موارد، به سراغ کد برید. همیشه سعی کنید تا کد رو طبق ۲ قائده‌ی کلی بررسی کنید: خوانایی و عملکرد.

و همیشه موقع خوندن کد از خودتون بپرسید، میشه این کد رو بهتر کرد؟ امکان داره این کد مشکلی برای برنامه به وجود بیاره؟

بررسی خوانایی کد

توجه داشته باشید که کد نوشته شده با گذشت زمان هم بتونه کدی خوب باشه. یاتون باشه اگر کدی که الان می‌خونید درکش براتون سخته، طبیعتا چندین ماه بعد براتون میتونه کاملا نامفهوم باشه. پس هر قطعه‌ای از کد باید کاملا قابلیت نگهداری در طول زمان رو داشته باشه. maintenance!

– به غلط های نگارشی توجه کنید. این خطا برای هرکسی در هر سطحی که باشه امکان داره رخ بده. اسم متغیرها، توابع و حتی نام فایل‌ها رو بررسی کنید تا درست نوشته شده باشن.

– متغیرها، توابع و کلاس ها درست نامگذاری شده باشن. یعنی یک تابع به خوبی مفهوم کاری که قرار هست انجام بده رو برسونه.

– در بخش‌های مهم کد کامنت‌های مفید قرار داشته باشن. یک کامنت لازم نیست خیلی طولانی باشه. اگر یک کامت طولانی برای بخشی از کد نوشته شده، پس طبیعتا اون قسمت نا مفهوم نوشته شده!

– اگر عبارت‌هایی مثل print لابلای کد دیدید، به برنامه نویس بگید که اون‌ها رو حذف کنه. (شاید بعد از دیباگ یادش رفته که اینکار رو کنه.)

– یک تابع باید در نزدیک ترین حالت ممکن یک مقدار رو return کنه. برای مثال به کد زیر توجه کنید:

if serializer.is_valid():
    .....
    .....
    .....
    return success_response()
else:
    return bad_request()

ما می‌تونیم کد بالا رو به صورت زیر refactor کنیم:

if not serializer.is_valid():
    return bad_request()
....
....
....
return success_response()

با این کار از if/elseهای تو در تو جلوگیری می‌کنیم و خوانایی کد برای دیگران راحت‌تر می‌شه.

بررسی عملکرد کد

شما همچنین باید به جزییات کاری که کد انجام میده و حتی مقیاس پذیری کد نوشته هم توجه کنید. همیشه این سوال‌ها رو از خودتون بپرسید:

– آیا حلقه‌ها، دستورات شرطی و یا عبارت‌هایی غیر ضروری داخل کد نوشته شده؟

– ویژگی Single responsability برای کلاس‌ها و توابع رعایت شده و تست اون‌ها به سادگی انجام میشه؟

– آیا کد قابلیت شکست داره؟ به عبارت دیگه تمام حالات ممکن بررسی شده و خطاهای احتمالی به خوبی مدیریت شده؟

– اگه من جای هم تیمیم بودم این کار رو چطور انجام می‌دادم؟ آیا راه حل من بهتر است و باعث بهبود کد میشه؟

هیچ کدی کاملا بی نقص نیست

شما به عنوان یک code reviewer باید بدونید کدی که در حال بررسی اون هستید، ممکنه کاملا به بهترین حالت ممکن نوشته نشده باشه. اگه روش بهتری می‌دونید به همکارتون بگید؛ نظرات خودتون رو براش کامنت کنید تا بتونید کد رو بهبود بدین. اگه هم روشی ندارید، پس اهمیت کار دیگران رو زیر سوال نبرید. شاید از دید شما یک تیکه کد باشه. اما همون شاید بتونه یک مشکل بزرگ برنامه‌ی شما رو حل کنه!

نظرات شما مرجع نیستند!

همه‌ی ما در مورد نحوه‌ی چگونگی نوشتن بخش‌های مختلف یک برنامه نظرات خودمون رو داریم و با سبک خاص خودمون برنامه‌هامون رو می‌نویسیم. اما در هنگام بررسی کد باید نظرات شخصیمون رو دور بندازیم! وقتی شما راه حل دیگران رو برای حل یک مسئله بررسی می‌کنید، باید به استانداردها و نکات فنی توجه کنید. پس سلایق شخصی شما هیچ اهمیتی ندارن!

شاید شما نام توابع رو به صورت snake_case می‌نویسید، اما نویسنده‌ی کدی که کد اون رو مرور می‌کنید، به صورت camelCase نوشته. بهترین کار چیه؟ کامنت بذارید و در مورد نامگذاری‌ها بهش اطلاع بدید؟ نه! شما باید از قبل، روی یک استاندارد کلی در مورد چنین مواردی با تمام تیم توافق کنید و براساس استانداردها پیش برید. استانداردهای تیم حرف اول رو می‌زنن.

اختلافات در تیم را حل کنید

ممکن هست یک code reviewer موقع بررسی کد، نظری اشتباه برای یک برنامه نویس تیم نوشته باشه. اما پس از اینکه فهمید کد رو درست متوجه نشده و نظری که داد اشتباه بوده، باز هم از موضع خودش کوتاه نیومده و همین باعث بحث در تیم شده.

عمل code review رو با درگیری و جدل اشتباه نگیرین. برنامه نویسی که کد اون رو بررسی می‌کنید حریف شما نیست! همه‌ی شما داخل یک تیم کار می‌کنید و برای هدفی مشترک تلاش می‌کنید. قبل از هرکاری شما باید به اتفاق نظر برسید. طبیعتا در بستری مثل Gitlab یا Bitbucket و با نوشتن کامنت چنین اختلاف‌های بزرگی حل نمی‌شن. بهترین راهکار برقراری تماس با همکارتون و صحبت کردن در مورد چنین مسائلی هست.

درباره‌ی کد نظر بدین، نه شخص

هنگام بررسی یک کد سعی کنید به دور از هرگونه احساسی نسبت به شخصی که کد اون رو مرور می‌کنید نظر بدین. بعضی اوقات کدی رو می‌بینیم که واقعا بد نوشته شده و باعث عصبانیت ما می‌شه. اول از همه سعی کنین آرامش خودتون رو حفظ کنید. و بعد از چند دقیقه که آروم شدین نظرتون رو برای هم تیمیتون بنویسید.

نظراتتون رو به صورت: «این کار رو نکن و از این روش استفاده کن» ننویسید. راه حل بهتر رو توضیح بدین و دلیل بهتر بودن رو ذکر کنید. می‌تونید لینکی به یک مقاله‌ی مفید هم بدین تا هم تیمی شما اون رو بخونه و اطلاعات بیشتری بدست بیاره. اما به هیچ وجه راه حل کامل مسئله رو داخل کامنت ننویسید. code review نباید کل وقت شما رو بگیره. این وظیفه‌ی شما نیست تغییرات لازم رو برای همکارتون بنویسید.

یک code reviewer خوب باشید

اگه موقع بررسی یک کد راه حل خوبی از همکارتون دیدید به اون اشاره کنید و از نحوه‌ی کد نویسیش تعریف کنید. بررسی یک کد فقط مربوط به ثبت نظر در مورد اشتباهات نیست. بازخورد مثبت بدین. مربی خوبی باشید و مثل یک سنیور رفتار کنید. نظر مثبت شما می‌تونه باعث ایجاد انگیزه‌ی بیشتر و بالا رفتن روحیه همکارتون بشه.