در نوشته های قبلی فهمیدیم که لازم است ریفکتور(بازسازی یا اصلاح کد) داشته باشیم. و اما یک قانون:
قانون 3
چه زمانی باید ریفکتور کرد؟
وقتی که فیچر جدیدی اضافه میکینم خیلی وقتها مجبور میشویم اول کدهای کثیف قبلی را تمیز کنیم تا بفهمیم چه کار می کنیم. تمیز کردن کد کار را برای نفرات بعدی هم ساده تر می کند
حالا که برای رفع یک باگ تا اینجای کد آمده ایم! حیف نیست که کد آن را تمیز نکنیم و رد شویم. با این کار یک تیر و دو نشان زده ایم. هم باگ رفع شده و هم قسمتی از کد تمیز شده است.
شاید این مرحله آخرین مرحله از خداحافظی شما با آن کد باشد و به این زودی ها به آن برنگردید. در این زمان هم می شود ریفکتور را در نظر گرفت. در این مرحله اشکالات ساده را برطرف می کنیم و زمان برای رفع اشکالات بزرگتر را برآورد می کنیم.
ریفکتورینگ باعث ساده سازی و قابل فهم شدن کد می شود اما باید تاثیرات پرفورمنسی آن در نظر گرفته شود و ضمنا نباید باعث ایجاد functionality جدید بشود.
نفس ریفکتور در جلسات بازبینی کد نباید باعث جلوگیری از merge یا check-in کد شود.