فرهنگ بازبینی کد
بازبینی کد در بیشتر تیمها یکی از این دو حالت است: یا تشریفاتی است و کسی بدون خواندن تأیید میکند، یا میدان جنگ است و آدمها از فرستادن کد میترسند.
هر دو نتیجهٔ یک سوءتفاهماند دربارهٔ اینکه بازبینی کد اصلاً برای چیست.
بازبینی برای پیدا کردن باگ نیست
این ادعای بحثبرانگیزی است، پس بگذارید دقیق بگویم: بازبینی کد بعضی باگها را پیدا میکند، اما اگر معیار موفقیتش این باشد، سرمایهگذاری بدی است. تست خودکار در پیدا کردن باگ ارزانتر و قابلاتکاتر است و خسته هم نمیشود.
ارزش واقعی بازبینی سه چیز دیگر است:
پخش دانش. بعد از بازبینی، دستکم دو نفر میدانند این بخش چطور کار میکند. این تنها بیمهٔ واقعی در برابر رفتن یک نفر است. در تیمهای دورکار که آن انتقال طبیعی دانش را ندارند، این تقریباً تنها کانال است.
یکدستماندن کد. بدون بازبینی، هر برنامهنویس سبک خودش را دارد و بعد از دو سال، سامانهای دارید که پنج زبان مختلف در آن نوشته شده.
تشخیص مسیر غلط، زودتر. بازبین معمولاً زودتر از نویسنده میبیند که راهحل دارد پیچیده میشود — چون درگیر جزئیاتش نبوده.
اگر بازبینی را با این هدفها ببینید، بیشتر تصمیمهای عملی خودشان روشن میشوند.
اندازه، مهمترین متغیر
اگر فقط یک چیز از این مقاله بردارید، این باشد: بازبینی بزرگ، بازبینی نشده است.
تغییری با هشتصد خط، در عمل خوانده نمیشود. بازبین بالا و پایین میکند، چند نکتهٔ سطحی میگوید — نام متغیر، فاصلهگذاری — و تأیید میکند. این نه کیفیت اضافه میکند و نه دانش پخش میکند؛ فقط زمان میگیرد.
تغییری با صد خط، واقعاً خوانده میشود.
پس مسئلهٔ اصلی بازبینی، در خود بازبینی نیست؛ در شکستن کار است. اگر کارهایتان دوهفتهای باشند، بازبینیهایتان هم بزرگ خواهند بود و هیچ فرهنگی نجاتشان نمیدهد.
قاعدهٔ عملی: تغییری که در بیست دقیقه قابل بازبینی نیست، باید شکسته شود.
چه چیزی را نگاه کنیم
اینها را در ترتیب اهمیت نوشتهام، که تقریباً برعکس ترتیبی است که در بیشتر بازبینیها اتفاق میافتد:
۱. آیا این راهحل درست مسئله است؟ گاهی کد بیعیب است و مسئله را حل نمیکند، یا مسئلهای را حل میکند که نباید. این گرانترین چیزی است که میشود دیر فهمید.
۲. حالتهای مرزی و خطا. ورودی خالی، مقدار منفی، سرویس بیرونی که پاسخ نمیدهد. اینجا بازبینی واقعاً از تست بهتر عمل میکند، چون بازبین میتواند حالتی را تصور کند که نویسنده به آن فکر نکرده — و به همین دلیل تستش را هم ننوشته.
۳. امنیت و دسترسی. آیا بررسی مجوز انجام شده؟ ورودی کاربر مستقیم در کوئری رفته؟ دادهای در لاگ نشسته که نباید؟
۴. خوانایی برای نفر بعدی. آیا شش ماه بعد کسی این را میفهمد؟
۵. سبک و قالببندی. آخرین، و راستش نباید اصلاً دستی بررسی شود. ابزار قالببندی خودکار این بحث را برای همیشه تمام میکند. تیمی که در بازبینی سر فاصلهگذاری بحث میکند، یک ابزار کم دارد نه یک قاعده.
چطور نظر بدهیم
اینجا جایی است که فرهنگ ساخته یا خراب میشود. چند قاعده که در تیمهایمان جواب داده:
دربارهٔ کد بنویسید، نه دربارهٔ آدم. «این تابع در حالت خالی خطا میدهد» نه «چرا حالت خالی را چک نکردی».
سطح نظر را مشخص کنید. هر نظری وزن یکسان ندارد و اگر این را نگویید، بازبین تازهکار همه را دستور میفهمد. ما سه سطح داریم و صریح مینویسیمشان: «باید» (تا اصلاح نشود ادغام نمیشود)، «پیشنهاد» (بهتر است اما اختیاری)، «صرفاً برای اطلاع». این یک تغییر کوچک است که تنش را بهطور نامتناسبی کم میکند.
دلیل بیاورید. «این را عوض کن» چیزی یاد نمیدهد. «این کوئری در حلقه است و با هزار ردیف هزار بار اجرا میشود» یاد میدهد.
آنچه خوب است را هم بگویید. بازبینیای که فقط ایراد میگیرد، آدمها را از فرستادن کد میترساند و نتیجهاش تغییرهای بزرگتر و کمتعدادتر است — یعنی دقیقاً همان چیزی که نمیخواهید.
اگر بحث از دو رفتوبرگشت گذشت، تماس بگیرید. بحث نوشتاری طولانی روی کد، تقریباً همیشه به سوءتفاهم میرسد. پنج دقیقه گفتوگو تمامش میکند.
و از طرف نویسنده
توضیح بنویسید. بازبین باید بداند این تغییر چه مسئلهای را حل میکند و چرا اینطور. بدون آن، بازبینی به حدسزدن تبدیل میشود.
نظر را رد کردن اشکالی ندارد. بازبینی مذاکره است، نه دستور. اگر دلیل دارید بنویسیدش؛ بازبین ممکن است چیزی را ندانسته باشد.
بازبینی به کد شماست، نه به شما. این جمله کلیشه است و در عمل سخت. راهی که کمک میکند: هرچه تغییرها کوچکتر باشند، سرمایهگذاری عاطفی روی هرکدام کمتر است.
زمان پاسخ
بازبینیای که سه روز منتظر میماند، دو هزینه دارد: نویسنده کار دیگری شروع میکند و بعداً باید به این برگردد، و تغییر با کدهای جدید تداخل پیدا میکند.
قاعدهای که در تیمهای ما هست: بازبینی در همان روز کاری. نه بلافاصله — قطعکردن کار عمیق برای بازبینی هم بد است — اما پیش از پایان روز.
و اگر فرصت نمیکنید، همان را بگویید تا کسی دیگر بردارد. سکوت بدترین پاسخ است.
چه چیزی را به ابزار بسپاریم
هرچه در بازبینی دستی بررسی میشود و قابل خودکارسازی است، باید خودکار شود. دلیلش فقط صرفهجویی نیست: نظر ابزار شخصی نیست و بحث نمیآفریند.
- قالببندی: ابزار خودکار، بدون استثنا.
- خطاهای شایع و الگوهای مشکوک: تحلیل ایستا.
- شکستن تستها: در خط لولهٔ CI/CD، پیش از اینکه کسی نگاه کند.
- وابستگیهای آسیبپذیر: بررسی خودکار.
آنچه میماند، همان چیزی است که واقعاً به قضاوت انسان نیاز دارد — و همان است که ارزش وقت بازبین را دارد.
آیا همهچیز باید بازبینی شود؟
جواب صادقانه: نه لزوماً، اما استثناها را از قبل تعریف کنید نه در لحظه.
استثناهای معقول: تغییر محتوای متنی، بهروزرسانیهای خودکار وابستگی، اصلاح فوری در قطعی سرویس (که بعداً بازبینی میشود).
آنچه هرگز استثنا نمیشود: هر چیزی که به پول، دسترسی یا دادهٔ شخصی دست بزند.
اگر تازه شروع میکنید
تیمی که تا حالا بازبینی نداشته، با «از فردا همهچیز بازبینی میشود» به مقاومت میخورد. مسیری که در پروژههای ما جواب داده:
۱. اول ابزار قالببندی و تحلیل ایستا را بگذارید — بحثهای بیارزش را از میدان خارج میکند. ۲. بعد بازبینی را برای بخشهای حساس اجباری کنید، نه همهجا. ۳. وقتی تیم دید که مفید است، دامنه را باز کنید.
و مدیر فنی باید اولین کسی باشد که کدش بازبینی میشود. تا وقتی استثنایی وجود داشته باشد، این کار بهعنوان کنترل فهمیده میشود، نه بهعنوان همکاری.