رهام رفیعی تهرانی
رهام رفیعی تهرانی
خواندن ۱ دقیقه·۳ سال پیش

چه موقعیتی برای ریفکتور مناسب نیست؟


وضعیتی را تصور کنید که یک باگ جدید به شما ارجاع داده شده است. اولویتش بسیار بالاست، مدیران میانی منتظرند شما به سرعت مشکل را حل کنید و می پرسند: "به مشتری چه جوابی بدهیم؟ بگوییم مشکل از کجاست؟"

شما به کد نگاهی می اندازید و سعی می کنید علت را پیدا کنید. ممکن است علت را در بخشی از کد ببینید که برای مدتی طولانی دست نخورده باقی مانده است. ممکن است بخشی از یک تغییر قدیمی جا مانده باشد. ممکن است مشکل از یک ماژول جانبی با نسخه ای قدیمی باشد و اکنون نیاز به به روز رسانی داشته باشد. ناگهان این ایده به ذهنتان خطور کند که اکنون وقت مناسبی برای ریفکتور کردن این بخش از کد است.


نکنید. الان ریفکتور نکنید.

شما به عنوان یک مهندس، حل مسئله می کنید و وظیفه شما اینجا این است که مسئله ای را وجود دارد، حل کنید. قرار نیست کار دیگری انجام دهید. اما این تصمیم به معنی قربانی کردن کیفیت نیست. حتی در این وضعیت هم ما همچنان:

  • یک برنچ (branch) می سازیم.
  • مسئله را برطرف کرده و commit می کنیم
  • هر چقدر که لازم است code review می کنیم
  • تغییرات را با بدنه نرم افزار ادغام می کنیم

نکته مهم این است که ما می خواهیم هر چه سریعتر مشکل را برطرف کنیم ولی نه به هر بهایی.

این مسیری است که می توانیم برای حل یک باگ انتخاب می کنیم:

?باگ را پیدا کن

?️‍♂️اون رو بررسی کن

سعی کن دوباره باگ را تولید کنی

?یک تست خطا برای باگ بنویس

?باگ را حل کن

?ببین که تست خطا پاس شده است

?تغییرات را ارسال کن

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