یکی از مهم‌ترین اصل‌های ریفکتور اینه که اول ریفکتور کنیم و بعد سراغ فیچر جدید بریم. ترکیب این دو کار معمولا باعث میشه تغییرات سخت‌تر بشن و تشخیص مشکل هم سخت‌تر بشه. بهتره اول کد رو به وضعیتی برسونیم که اضافه کردن فیچر جدید روی اون منطقی باشه.

تست‌ها هم توی ریفکتور نقش مهمی دارن. طبیعیه که بعد از یک ریفکتور بزرگ بعضی تست‌ها fail بشن، چون کد تغییر کرده. در کنار تست‌های اتوماتیک، نباید QA رو هم از فرایند حذف کنیم.

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

تا جای ممکن بهتره کارهای تکراری رو به ابزارها بسپاریم. IDE و linterها خیلی از ریفکتور‌های ساده مثل rename کردن رو با خطای کمتری نسبت به تغییر دستی انجام میدن. ریفکتور دستی رو بیشتر برای جاهایی نگه داریم که نیاز به تصمیم طراحی یا تغییرات بزرگ‌تر دارن.

#Skills_of_a_Successful_Software_Engineer

@techstuff100