درس 40: Refactoring
حین تکامل یک نرم افزار، پیش میاد که در مورد قسمت هایی از کد تجدید نظر کنیم و تغییراتی بدیم. این امر طبیعیه. کد نیاز به تکامل داره و یک چیز ثابت و ایستا نیست.
متاسفانه اصطلاح ساختن یا ساخت و ساز در مورد نرم افزار بعضا بکار میره. معمولا ساختن رو برای ساختمون بکار میبرن و یک همچین پروسه ای داره:
- معمار نقشه های اصلی رو ترسیم میکنه
- پیمانکاران شروع به ساخت میکنن از شناژ و پایه های ساختمان تا دیوارها و لوله و سیمکشی و سنگ و نما و ...
- ساکنین خوشحال سر و کله شون پیدا میشه و در خونه هاشون مستقر میشن.
ولی نرم افزار اینجوری نیست. پروسه تولید نرم افزار روح دار تر از ساخت ساختمونه و بیشتر شبیه به باغبانیه. شما طبق یک برنامه اولیه و شرایط موجود یکسری گیاه رو در باغچه تون میکارید. برخی شون رشد میکنن، برخی شون سقط میشن و به کود تبدیل شون میکنید، برای اینکه از حداکثر نور خورشید و یا باد و آب بهره ببرن ممکنه جابجاشون کنید، بعضی رو در تایم مشخص هرس میکنید، و دائما بر سلامت باغچه تون نظارت دارید و در صورت لزوم تنظیم آب و خاک و چیدمانشون رو تغییر میدید.
شاید بیزنس من ها و تجار با مفهومی مثل ساخت ساختمون راحت تر باشن، چون همه چیز واضح و مشخصه، یکسری روال و عملیات که طبق یک ترتیب خاصی انجام میشن تا محصول نهایی آماده بشه ولی دنیای نرم افزار بیشتر مثل روال باغبونیه.
طبق تعریف مارتین فاولر(نویسنده و سخنران حوزه علوم نرم افزاری):
ریفاکتور کردن روش منظمی برای تغییر ساختار کد موجود، به شکلی که ساختار داخلی تغییر بکند، بدون اینکه ساختار خارجی و رفتار اون تغییر بکنه.
دو نکته مهم این تعریف:
• این عملیات نظم و جای خاصی داره و شامل هرجایی نمیشه
• رفتار خارجی قرار نیست تغییر بکنه، چون به این معنی نیست که قراره فیچری اضافه بشه.
برای اینکه گارانتی کنید رفتار خارجی کد تغییری نکرده باید تست های اتومات خوبی داشته باشید که رفتار کدتونو بررسی کنه.
WHEN SHOULD YOU REFACTOR?
وقتی ریفاکتور میکنید که چیز جدیدی یاد گرفتید و متوجه شدید روش جدید که از کاری که سال قبل یا ماه قبل یا ده دقیقه پیش انجام دادید، بهتره. وقتی کدی رو واجد شرایط ریفاکتور پیدا میکنید، توی تغییرش درنگ نکنید، چون بهترین وقت همین زمان حاله.
یکسری موارد شایع وجود داره که در صورت دیتکت شون بدونید باید ریفاکتور کنید:
• Duplication
کدی رو پیدا کردید که داره اصل DRY رو نقض میکنه و تکرار محسوب میشه
• نقص اصل جداسازی decoupling
وقتی کد یا بخش هایی از کد رو پیدا میکنید که اصل جداسازی رو رعایت نکردن و با تغییر یکی شون مابقی خراب یا باگ دار میشه
• دانش قدیمی
شما با کدی مواجه میشید که دانش بیزنسی قدیمی رو اعمال کرده بودید
• Performance
کدی یا بخشی رو پیدا کردید که میتونید بهبودی توی پرفورمنسش بدید
این واقعیت هم وجود داره که عمل ریفاکتورینگ، عمل دردناکیه، شما رو متحمل سختی میکنه و همچنین دقت بالایی رو باید بخرج بدید، خیلی از دولوپرها متاسفانه بر این عقیده ان که تا زمانی که کار میکنه چرا بهش دست بزنیم، اما اگر بهبود ندید و اپدیتش نکنید کل سیستم تون زیر سوال میره. قطعا ریفاکتور کردن عوارضی داره. مهمترینش زمانی که باید بزاریده اونم با وجود فشار زمانی روی پروژه هاست اما رسیدگی نکردن بهش میتونه مثل یک توده سرطانی کوچیک باشه که اگر خیلی زود بهش رسیدگی بشه با یک درمان دارویی کوتاه رفع میشه ولی اگر رسیدگی نشه توی بدن پخش میشه و با کلی درد و خطر و حتی شکست باید بهش رسیدگی کنید.
واضح است که ریفاکتور کردن فعالیتیه که باید به آرومی، آگاهانه و با دقت انجام بشه. مارتین فاولر نکات ساده زیرو در مورد چگونگی ریفاکتور کردن و آسیب نرسوندن میگه:
• سعی نکنید عمل ریفاکتور کردن رو با افزودن فیچر باهم و در یک زمان انجام بدید
• مطمئن باشید که تست های خوبی دارید قبل از اینکه ریفاکتور کنید.
• قدم های کوچیک بردارید و بعد هر قدم هم تست ها رو اجرا کنید، این از دیباگ کردن های طولانی و مشکلات پیش رو نجاتتون میده.
دروس مرتبط: 3, 9, 12, 27, 44, 48
منبع کانال تلگرامی: https://t.me/pragmaticprogrammer_fa
