Faragiri

همهٔ زبان‌ها

آموزش بازبینی کدکد تمیز نوشتن

هر نظر در بازبینی کد دو چیز کم دارد: اینکه مسدودکننده است یا نه، و درجه اطمینان نویسنده‌اش. هر دو در یک کلمه جا می‌شوند.

۴بخش
۳دقیقه خواندن
۴عمق

دو پرسش، چهار نوع نظر

جلوی ادغام را می‌گیرد یا نه، و چقدر مطمئنید

هر نظری در یکی از این چهار خانه می‌افتد، و نوشتن نام خانه در ابتدای نظر بیشتر بحث‌ها را حذف می‌کند.

مطمئنممطمئن نیستم

جلوی ادغام را می‌گیرد

مسدودکنندهادعای مشخص با دلیل، و بهتر است با یک ورودی نمونه
  • این آخرین سطر را می‌اندازد
نگرانیشاید اشتباه کنم، ولی این حالت را بررسی کنید
  • اگر فهرست خالی باشد چه می‌شود

جلوی ادغام را نمی‌گیرد

نکتهبخواهید بگیرید نخواهید نگیرید، و هیچ‌کس منتظرش نمی‌ماند
  • با بازگشت زودهنگام خواناتر می‌شود
پرسشکنجکاوی، و نه درخواست تغییر پنهان‌شده در قالب پرسش
  • چرا اینجا از دیکشنری استفاده نشد

این شبکه درباره اندازه تغییر چیزی نمی‌گوید. روی یک تغییر هزار سطری، هر چهار خانه پر می‌شوند و هیچ‌کدام خوانده نمی‌شوند.

بیشتر نظرهایی که در بازبینی کد نوشته می‌شوند دو اطلاع لازم را ندارند و همین است که بحث را طولانی می‌کند: اینکه این نظر جلوی ادغام را می‌گیرد یا نه، و اینکه نویسنده‌اش چقدر مطمئن است. هر دو با یک کلمه در ابتدای نظر حل می‌شوند.

  • مسدودکننده. «این آخرین سطر را می‌اندازد: range یکی زودتر تمام می‌شود.» ادعای مشخص، با دلیل.
  • نکته. «نکته، بخواهید بگیرید نخواهید نگیرید: این شرط با یک بازگشت زودهنگام خواناتر می‌شود.»
  • پرسش. «کنجکاوم بدانم چرا اینجا از دیکشنری استفاده نشد» و نه درخواست تغییر.
  • تحسین. کوتاه و مشخص، برای همان بخشی که واقعا خوب حل شده.

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

دنبال چه باید گشت، و به چه ترتیبی

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

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

اندازه‌ای که بازبینی را ممکن می‌کند

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

جایی که کار گیر می‌کند، سلسله‌مراتب است

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

ابزار، و سالی که این حرف درست است

در سال ۲۰۲۶ بازبینی روی درخواست ادغام در GitHub یا GitLab انجام می‌شود و هر دو نظر روی سطر و پیشنهاد تغییر مستقیم دارند؛ پیشنهاد تغییر جای نوشتن «این سطر را به این شکل عوض کن» را گرفته و نویسنده با یک کلیک اعمالش می‌کند. برای اینکه سبک اصلا وارد بحث نشود، ruff را در همان خط لوله اجرا کنید تا پیش از رسیدن به بازبین گزارش دهد؛ رایگان است. دسترسی به هر دو سرویس از ایران پایدار نیست و تیم‌های زیادی نمونه خودمیزبان GitLab را بالا می‌آورند، که همان امکانات بازبینی را دارد.

پرسش بعدی این است که وقتی نظرها حل شدند، چه چیزی تضمین می‌کند تغییر بعدی همان باگ را برنگرداند، که یک چیز در هر بار، سریع و جدا است. و مکانیک خود درخواست ادغام در پیشنهاد دادن یک تغییر، و بازبینی یکی است.

کنار این

بالای این