مقدمه مترجم
مطالب زیر از نسخه اصلی کتاب Refactoring: Improving the Design of Existing Code نوشته Martin Fowler دستچین شده و با ترجمه همراه با تالیف برای درک بهتر مطلب آمده است. Code Refactoring به شما یک سری عادت مفید در برنامه نویسی می آموزد که بسیار میتواند باعث کیفیت بخشیدن به نرم افزارتان شود. مطالب در این رابطه به مرور روی وبلاگ قرار می گیرند و به امید خدا این مطالب را در ویکی پدیا فارسی هم در بخش Code Refactoring اضافه خواهم کرد.
Refactoring یا بازآرایی چیست؟
بازآرایی فرایند تغییر یک سیستم نرم افزاری به گونه ای است که رفتار خارجی تغییر نکند و ساختار داخلی بهبود یابد. این یک روش منظم برای پاکسازی کد به گونه ای هست که شانس رخدادن خطا کاهش یابد. درواقع بازآرایی کردن معادل بهبود طراحی کد بعد از نوشته شدن می باشد.
"بهبود طراحی پس از نوشته شدن کد" عبارت عجیبی است زیرا با درک حال حاضر ما از توسعه نرم افزار ما بر این باور داریم که اول طراحی میکنیم و بعد برنامه نویسی را انجام میدهیم. یک طراحی خوب داریم و بعد از آن سراغ برنامه نویسی می رویم. پس از گذشت زمان کد و درستی سیستم تغییر پیدا میکند و ساختار طراحی بمرور محو میشود. کد به آرامی از فرآیندی مهندسی به فرآینی شبیه خنثی سازی بمب شبیه میشود.
بازآرایی معکوس فرایند مطرح شده در بالاست با بازآرایی شما میتوانید با یک طراحی بد یا بی نظمی کامل شروع کنید و با دوباره کاری کد را به یک طراحی درست برسانید. هر گام ساده هست شما یک متغیر را از یک Class به Class دیگر منتقل می کنید بخشی از کد یک تابع را جدا میکنید و یک تابع جداگانه می سازید. بخشی از کد را به Class های بالاتر و یا پایین تر منتقل میکنید و بعد مجموع تاثیرات این تغییرات کوچک میتواند به طرز چشم گیری طراحی را بهبود بخشد. این دقیقا برعکس مفهوم رایج پوسیدگی نرم افزار [1] میباشد.
با بازآرایی شما توازن را در تغییرات پیدا می کنید و بجای ساختن تمامی طرح از اول به مرور در حین فرایند توسعه به طراحی مناسب دست پیدا میکنید. شما از ساخت سیستم نحوه بهبود طراحی را یاد میگیرید. نتیجه این تغییرات به یک طراحی منجر میشود که با ادامه فرآیند توسعه کیفیت خود را حفظ می کند.
[1] Software decay
چرا باید بازآرایی کرد؟
قرار نیست بازآرایی را یک علاج برای همه نوع نرم افزار معرفی کنیم. بازآرایی یک ابزار ارزشمند است که مانند یک انبر به شما کمک میکند که کدتان را هرس کنید. بازآرایی یک ابزار است که میتواند، و هچنین باید برای چندین هدف استفاده شود.
بازآرایی طراحی نرم افزار را بهبود می بخشد
بدون Refactoring طراحی نرم افزار بمرور پوسیده میشود وقتی برنامه نویسان کد را تغییر میدهند دنبال هدف های کوتاه مدت بدون توجه به طراحی کد هستند و وقتی کد ساختارش را از دست می دهد درک طراحی با خواندن کد سخت تر میشود. Refactoring شبیه تمیز کردن و مرتب کردن کد است این کار برای حذف بخش هایی که در مکان درست نیستند انجام میشود از دست رفتن ساختار کد اثر مخربی دارد هرچه دیدن طراحی سخت تر شود حفظ کردن طراحی هم سخت تر میشود و سریعتر پوسیده میشود. Refactoring به صورت مرتب به کد کمک میکند تا شکل اش را حفظ کند.
یک کد با طراحی بد معمولا نیاز به کد بیشتر برای انجام یک کار دارد بخاطر اینکه این کد درواقع یک کار را در چندین مکان انجام میدهد در نتیجه یکی از مهم ترین جنبه های بهبود طراحی حذف کد های تکراری است این برای انجام تغییرات آینده در کد مفید است. کم کردن مقدار کد سبب سریعتر اجرا شدن سیستم نمی شود چون این تاثیر در ردپای نرم افزار خیلی کم مشخص است. در عوض کم کردن مقدار کد یک تغییر بزرگ برای تغییرات سیستم در آینده ایجاد میکند. هرچه کد بیشتر باشد تغییر درست سیستم نیز سخت تر میشود. با از بین بردن تکرارها در کد شما مطمئن میشوید که کد همه چیز را فقط یکبار گفته است این ماهیت یک طراحی خوب است.
بازآرایی باعث درک راحت تر نرم افزار میشود
برنامه نویسی در خیلی از حالات مثل یک مکالمه با کامپیوتر است شما کد هایی را مینویسید که به کامپیوتر میگویید چه کاری انجام دهد و کامپیوتر جواب شما را با انجام دقیق گفته های شما می دهد. شما میتوانید با کوتاه کردن حرف و دقیقا چیزی را که میخواهید از کامپیوتر طلب کنید اما برنامه نویس دیگری نیز ممکن است بخواهد چند ماه آینده کد شما را بخواند و برخی تغییرات را در کد اعمال کند شما این فرد را فراموش کردید. این برنامه نویس بیشترین اهمیت را دارد، چه اهمیتی دارد که کامپیوتر چند سیکل CPU بیشتر برای کامپایل وقت بگذارد؟ اما این مهم است اگر یک برنامه نویس یک هفته برای یک تغییر که با درک کد شما یک ساعته قابل انجام بود وقت بگذارد.
بازآرایی به شما در پیدا کردن باگ کمک میکند
وقتی بازآرایی باعث میشود شما درک راحت تری از کد داشته باشید حتما در صورت وجود باگ به آن پی می برید برنامه نویس های کمی هستند که در انبوهی از کد میتوانند تحلیل خوبی داشته باشند و باگ را پیدا کنند اما با استفاده از Refactoring عامل مشکل ساز را پیدا میکنید یک جمله معروف از Kent Beck وجود دارد که میگوید "من یک برنامه نویس فوق العاده نیستم، من یک برنامه نویس معمولی با عادت های فوق العاده هستم". Refactoring به شما کمک میکند که در نوشتن کد های بزرگ کاراتر باشید.
بازآرایی سرعت برنامه نویسی شما را افزایش میدهد
در پایان این نکات به این میرسیم که بازآرایی باعث میشود شما سریعتر برنامه نویسی کنید. شاید عجیب بنظر برسد معمولا وقتی راجع به بازآرایی صحبت میکنیم مردم به راحتی متوجه میشوند که این روش کیفیت را افزایش میدهد طراحی را بهبود می بخشد خوانایی را بهتر می کند باگ را کم می کند ولی تمامی این کارها موجب کند تر شدن برنامه نویسی نمیشود؟
یک طراحی خوب لازمه توسعه نرم افزار سریع است و کل هدف یک طراحی خوب اجازه دادن برای یک توسعه سریع است. بدون یک طراحی خوب در ابتدا با سرعت بالا جلو میروید اما بزودی طراحی ضعیف سرعت شما را کم می کند. مجبورید زمان را بجای صرف کردن برای اضافه کردن قابلیت جدید صرف پیدا کردن و خنثی کردن باگ ها کنید. وقتی شما بخواهید سیستم را درک کنید و کد های تکراری را تغییر دهید تغییرات کند تر میشوند. قابلیت های جدید نیازمند کد های بیشتری هستند وقتی مدام ساختار کد اصلی را وصله میزنید.
یک طراحی خوب یک اصل در بالابردن سرعت توسعه نرم افزار است Refactoring به شما کمک می کند نرم افزار را سریعتر توسعه دهید چون از پوسیدگی طراحی سیستم جلوگیری می کند حتی میتواند طراحی را بهبود بخشد.
Bad Smells یا بو های بد در کد
تا الان شما با نحوه عملکرد بازآرایی آشنا شدید، ولی با دانستن اینکه چطور کار می کند نمیتوان فهمید که کی نیاز به Refactor داریم. تصمیم گیری در مورد زمان شروع بازآرایی و زمان پایان به اندازه دانستن نحوه استفاده از خود فرآیند بازآرایی مهم است.
حالا به یک دو راهی میرسیم توضیح دادن نحوه حذف یک نمونه متغیر یا ایجاد ارث بری آسان است. اینها مشکلات آسان هستند اینکه کی باید این تغییرات را اعمال کنیم خیلی زمانمند و مقرراتی نیست. بجای پیروی کردن از چند مفهوم و نشانه زیبایی شناختی برنامه نویسی ( که صراحتا کاری که معمولا انجام میدهیم این است) معیار های سفت و سخت تری نیاز می باشد.
معیار ها در بازآرایی دارای ضوابط دقیق نیستند که کی Refactoring تمام میشود. تجربه نشان داده که همیشه مجموعه معیار ها از هوش انسان ضعیف تر میشوند. وقتی گفته میشود از class زیاد شی نسازید یا تعداد خط های موجود در یک تابع نباید زیاد شود شما میبایست تفسیر خودتان از زیاد را داشته باشید. عبارت بوی بد نشان دهنده طراحی نادرست میباشد و در ادامه انواع stink یا بو های بد را بررسی میکنیم.
22 نوع بوی بد در کد وجود دارد:
- کد های تکراری Duplicated Code
- تابع طولانی Long Method
- کلاس بزرگ Large Class
- لیست پارامتر طولانی Long Parameter List
- تغییرات واگرا Divergent Change
- تشریح انفجاری Shotgun Surgery
- خصیصه حسادت Feature Envy
- توده داده Data Clumps
- وسواس اولیه Primitive Obsession
- دستور سوییچ Switch Statements
- سلسله های وراثت موازی Parallel Inheritance Hierarchies
- کلاس تنبل Lazy Class
- عمومیت خطرناک Speculative Generality
- متغیر موقت Temporary Field
- زنجیر پیام Message Chains
- مرد واسطه Middle Man
- صمیمیت نامناسب Inappropriate Intimacy
- کلاس های جایگزین با interface متفاوت
- کلاس کتابخانه ناتمام Incomplete Library Class
- کلاس داده Data Class
- میراث بدردنخور Refused Bequest
- توضیحات Comments
۱۷ بهمن ۹۴، ۰۸:۴۶
تشکر از مطالب فید و خوبت. من این کتاب رو داشتم و هیچ وقت وقت نمی شد بخونمش الان گذاشتم تو برنامه هام گه بخونمش. مرسی.