مدتی است که کدهای دیگران را بازبینی می‌کنم و با گذر زمان، چیزهایی درباره‌ی کد ریویو مؤثر یاد گرفتم. در این مقاله، روی موضوعاتی تمرکز می‌کنم که وقتی تازه شروع کرده بودم، توجهی به آن‌ها نداشتم.
به تصویر کلی فکر کنید
ریویوهای بد، دید محدودی دارند. روی syntax، سبک نوشتاری و مسائل جزئی تمرکز می‌کنند، نه روی قابلیت نگهداری و توسعه‌پذیری.
بازبینی‌های خوب فقط تغییرات را نگاه نمی‌کنند، بلکه بررسی می‌کنند که این تغییرات چه مشکلی را حل می‌کنند، چه مسائل آینده‌ای ممکن است ایجاد شود و این تغییرات چطور در طراحی کلی سیستم جا می‌گیرند.
من دوست دارم به خطوطی نگاه کنم که تغییر نکرده‌اند. آن‌ها معمولاً داستان واقعی را روایت می‌کنند.
مثلاً خیلی وقت‌ها افراد فراموش می‌کنند بخش مرتبطی از کد یا مستندات را هم به‌روز کنند. این موضوع می‌تواند باعث باگ، سردرگمی، ناسازگاری یا حتی مشکلات امنیتی شود.
باید همه محل‌های فراخوانی کد جدید را بررسی کنید. آیا درست به‌روزرسانی شده‌اند؟ آیا تست‌ها هنوز چیز درستی را بررسی می‌کنند؟ تغییرات در جای مناسبی اعمال شده‌اند؟
پرسش‌هایی که هنگام بازبینی از خودم می‌پرسم:
- این کد چطور در بقیه سیستم جا می‌گیرد؟
- تعاملش با سایر بخش‌های کد چیست؟
- چه تأثیری روی معماری کلی دارد؟
- آیا روی کارهای آینده اثر می‌گذارد؟
این پرسش‌ها بیشتر به طراحی سیستم مربوط هستند تا خود تغییرات. تصویر کلی را نادیده نگیرید، چون اگر تغییرات ضعیف پذیرفته شوند، سیستم شکننده خواهد شد.
کد در خلأ نوشته نمی‌شود. نقش توسعه‌دهندگان باتجربه این است که اصطکاک عملیاتی را کاهش دهند و ریسک پروژه را مدیریت کنند. مستندات، تست‌ها و انواع داده‌ها به‌اندازه خود کد اهمیت دارند.
همیشه به دنبال انتزاع‌های بهتر باشید، چون کد تکامل پیدا می‌کند.
نام‌گذاری همه چیز است
بخش بزرگی از وقتم در بازبینی‌ها صرف فکر کردن به نام‌های خوب می‌شود.
نام‌گذاری سخت است و به همین دلیل بسیار مهم است. معمولاً حیاتی‌ترین بخش یک بازبینی کد همین نام‌گذاری است.
نام‌ها مفاهیم را در خود می‌گیرند و به‌عنوان «بلوک‌های سازنده» کد عمل می‌کنند. نام‌های بد بوی بد می‌دهند و نشان از مشکلات عمیق‌تر دارند. آن‌ها بار ذهنی را چندین برابر می‌کنند.
در پروژه‌های بزرگ که مقادیر در فاصله‌های دور از هم تعریف و استفاده می‌شوند و چندین توسعه‌دهنده باید درک مشترکی از دامنه داشته باشند، نام‌گذاری اهمیت حیاتی پیدا می‌کند.
از «نه» گفتن نترسید
بارها مجبور شده‌ام تغییرات را رد کنم، و این هیچ‌وقت کار آسانی نیست. اما بهتر است «نه» بگویید تا اینکه چیزی را بپذیرید که در آینده دردسرساز می‌شود.
در فرآیند بازبینی، هیچ تضمینی برای پذیرفته‌شدن کد وجود ندارد.
در پروژه‌های متن‌باز هم خیلی‌ها کدی می‌فرستند که با استانداردها هماهنگ نیست. کسی باید «نه» بگوید و این کار محبوبی نیست، ولی ضروری است.
گاهی افراد می‌گویند: «فعلاً مرج کنیم، بعد درستش می‌کنیم.» این یک سراشیبی خطرناک است که به بدهی فنی و کار اضافه منجر می‌شود.
یادتان باشد شما شخص را رد نمی‌کنید، بلکه کد را رد می‌کنید. تلاش او را ارج بگذارید و کمک کنید بهتر شود.
اگر بارها مجبورید به یک موضوع مشابه «نه» بگویید، بهتر است برای تیم یک راهنمای سبک یا قوانین مشخص تدوین کنید.
قاطع ولی محترمانه باشید، این فقط کد است.
بازبینی کد یعنی ارتباط
بازبینی کد فقط درباره‌ی کد نیست، انسان‌ها هم مهم‌اند. ایجاد رابطه خوب با همکاران حیاتی است.
بازبینی‌های اولیه را می‌توانید در جلسات برنامه‌نویسی دونفره (Pair Programming) انجام دهید. این باعث ایجاد اعتماد و ارتباط بهتر می‌شود.
بازبینی باید تکرارشونده باشد
بازبینی یک‌باره نیست. یک فرآیند تکرارشونده است. در دور اول، به تصویر کلی نگاه کنید. در دورهای بعدی به جزئیات بپردازید.
هدف، ادغام سریع نیست، هدف پذیرش کدی با کیفیت بالاست.
بازبینی علاوه بر یافتن ایراد، فرصتی برای ایجاد درک مشترک در تیم است.
نکات دیگر
- مودب باشید، نه بی‌ادب: به‌جای گفتن «این غلطه»، بگویید «من این‌طوری انجامش می‌دادم.»
- کد را اجرا کنید: خیلی چیزها موقع اجرا مشخص می‌شود.
- در دسترس بودن را شفاف کنید: اگر وقت بازبینی ندارید، به نویسنده اطلاع دهید.
- یادگیری مداوم: بازبینی‌ها بهترین فرصت برای یاد گرفتن روش‌ها، الگوها و دیدگاه‌های جدیدند.
- خرده‌گیری نکنید: فرمت و فاصله‌ها را به ابزارها (مثل eslint یا laravel pint و…) بسپارید؛ روی مسائل مهم تمرکز کنید.
- روی چرایی تمرکز کنید، نه چگونگی: دلیل تغییر را بپرسید و بفهمید.
- از پرسیدن نترسید: هیچ سؤالی احمقانه نیست. پرسیدن بهتر از فرض کردن است.
- بازخورد روی سبک کد ریویو بگیرید: از دیگران بپرسید نقد و نظرات شما چطور بوده و چطور می‌توانید بهتر شوید.
در نهایت، بازبینی کد یک مهارت است که نیاز به تمرین و تکامل دائمی دارد.
دیدگاهتان را بنویسید