نکات کلیدی
1. بازسازی: بهبود کنترلشده کد
بازسازی فرآیند تغییر یک سیستم نرمافزاری به گونهای است که رفتار خارجی کد را تغییر ندهد اما ساختار داخلی آن را بهبود بخشد.
تعریف و هدف. بازسازی به معنای افزودن ویژگیهای جدید یا رفع اشکالات نیست؛ بلکه بهبود طراحی داخلی کد موجود بدون تغییر رفتار خارجی آن است. این یک رویکرد منظم برای پاکسازی کد است که آن را قابل فهمتر، قابل تغییرتر و قابل نگهداریتر میسازد. هدف جلوگیری از زوال نرمافزار و اطمینان از این است که کد در طول زمان مقاوم و قابل انطباق باقی بماند.
استعاره دو کلاه. هنگام بازسازی، باید دو کلاه متفاوت بپوشید: یکی برای افزودن عملکرد و دیگری برای بازسازی. هنگام افزودن عملکرد، بر ویژگیهای جدید و تستها تمرکز میکنید. هنگام بازسازی، بر بازسازی کد بدون افزودن ویژگیهای جدید یا تستها تمرکز میکنید. این جداسازی نگرانیها به حفظ تمرکز کمک کرده و از معرفی اشکالات جلوگیری میکند.
فرآیند مداوم. بازسازی یک رویداد یکباره نیست بلکه یک فرآیند مداوم است که باید در چرخه توسعه گنجانده شود. این یک تلاش مستمر برای بهبود طراحی کد در حین کار بر روی آن است، نه یک فعالیت جداگانه که بهطور دورهای انجام میشود. این رویکرد اطمینان میدهد که کد در طول چرخه عمر خود تمیز و قابل نگهداری باقی بماند.
2. بوی کد: شناسایی نیازهای بازسازی
اگر بوی بدی میدهد، آن را تغییر دهید.
شاخصهای کد ضعیف. بوی کد نشانههایی از مشکلات بالقوه در کد است که نیاز به بازسازی را نشان میدهد. اینها لزوماً اشکالات نیستند، اما نشانههایی از طراحی ضعیف هستند که میتوانند به مشکلات آینده منجر شوند. بویهای رایج کد شامل:
- کد تکراری: کد مشابه یا یکسان در چندین مکان
- متد طولانی: متدهایی که بسیار طولانی و پیچیده هستند
- کلاس بزرگ: کلاسهایی که مسئولیتهای زیادی دارند
- لیست پارامتر طولانی: متدهایی با پارامترهای زیاد
- تغییر واگرا: کلاسهایی که به دلایل مختلف تغییر میکنند
- جراحی شاتگانی: تغییراتی که نیاز به اصلاحات در چندین کلاس دارند
- حسادت ویژگی: متدهایی که بیشتر به دادههای کلاس دیگر علاقهمندند
- خوشههای داده: گروههای داده که در چندین مکان ظاهر میشوند
- وسواس به نوعهای اولیه: استفاده بیش از حد از نوعهای داده اولیه به جای اشیاء
- عبارات شرطی: منطق شرطی مبتنی بر کدهای نوع
- سلسلهمراتب وراثت موازی: زیرکلاسهایی که یکدیگر را منعکس میکنند
- کلاس تنبل: کلاسهایی که به اندازه کافی کار نمیکنند تا وجودشان توجیهپذیر باشد
- عمومیسازی حدسزده: پیچیدگی غیرضروری برای نیازهای آینده
- فیلد موقتی: فیلدهایی که فقط در شرایط خاص استفاده میشوند
- زنجیرههای پیام: دنبالههای طولانی از فراخوانی متدها
- مرد میانه: کلاسهایی که بیشتر کارهای خود را واگذار میکنند
- نزدیکی نامناسب: کلاسهایی که بیش از حد به هم وابستهاند
- کلاسهای جایگزین با رابطهای مختلف: کلاسهایی که همان کار را با رابطهای مختلف انجام میدهند
- کلاس کتابخانه ناقص: کلاسهای کتابخانه که فاقد عملکرد مورد نیاز هستند
- کلاس داده: کلاسهایی که فقط دادهها را نگه میدارند
- ارثخواهی رد شده: زیرکلاسهایی که از متدهای ارثی استفاده نمیکنند
- نظرات: نظرات بیش از حد که نشاندهنده کد نامشخص هستند
موضوعی اما مفید. بوی کد موضوعی است، اما راهی عملی برای شناسایی نواحی کد که نیاز به توجه دارند، ارائه میدهد. اینها قوانین دقیقی نیستند بلکه راهنماهایی هستند که به شما کمک میکنند بر نواحیای تمرکز کنید که ممکن است از بازسازی بهرهمند شوند.
بینشهای عملی. بوی کد فقط به شناسایی مشکلات محدود نمیشود؛ بلکه همچنین بازسازیهای خاصی را پیشنهاد میکند که میتوانند برای حل آن مشکلات استفاده شوند. با شناسایی بویها، میتوانید تکنیکهای مناسب بازسازی را برای بهبود کد انتخاب کنید.
3. تست: سنگ بنای بازسازی ایمن
قبل از شروع به بازسازی، اطمینان حاصل کنید که مجموعهای قوی از تستها دارید. این تستها باید خودکنترل باشند.
ضروری برای بازسازی. تستها برای بازسازی حیاتی هستند زیرا شبکه ایمنی را فراهم میکنند که به شما اجازه میدهد با اطمینان تغییرات ایجاد کنید. بدون تستها، در معرض خطر معرفی اشکالات و شکستن عملکرد موجود هستید. تستها باید خودکنترل باشند، به این معنی که بهطور خودکار نتایج را تأیید کرده و هرگونه شکست را گزارش کنند.
تستهای خودکنترل. تستهای خودکنترل برای بازسازی کارآمد ضروری هستند. آنها نیاز به تأیید دستی را از بین میبرند و به شما اجازه میدهند تستها را بهطور مکرر و سریع اجرا کنید. این حلقه بازخورد سریع برای شناسایی و رفع اشکالات در مراحل اولیه فرآیند بازسازی بسیار مهم است.
توسعه مبتنی بر تست. نوشتن تستها قبل از نوشتن کد یک تکنیک قدرتمند است که میتواند طراحی و کیفیت نرمافزار شما را بهبود بخشد. با نوشتن تستها در ابتدا، نیازهای خود را روشن کرده و اطمینان حاصل میکنید که کد شما با آن نیازها مطابقت دارد. این رویکرد همچنین بازسازی را آسانتر میکند زیرا مجموعهای قوی از تستها برای اتکا دارید.
4. ترکیب متد: شکستن پیچیدگی
هر احمق میتواند کدی بنویسد که یک کامپیوتر بتواند آن را درک کند. برنامهنویسان خوب کدی مینویسند که انسانها بتوانند آن را درک کنند.
متدهای کوچک کلید هستند. متدهای کوتاه و با نام مناسب، درک، استفاده مجدد و تغییر آنها آسانتر است. آنها همچنین دیدن ساختار کلی کد را آسانتر میکنند. از سوی دیگر، متدهای طولانی درک و نگهداری آنها دشوار است.
استخراج متد. رایجترین بازسازی برای ترکیب متد، استخراج متد است که شامل شکستن یک متد طولانی به قطعات کوچکتر و قابل مدیریتتر است. این تکنیک خوانایی را بهبود بخشیده و جابجایی کد را آسانتر میکند.
تکنیکهای دیگر ترکیب. سایر بازسازیها برای ترکیب متد شامل:
- متد درونخط: جایگزینی فراخوانی متد با بدنه آن
- جایگزینی موقت با پرسش: جایگزینی متغیرهای موقتی با فراخوانی متد
- تقسیم متغیر موقتی: تقسیم یک متغیر موقتی به چندین متغیر
- حذف انتساب به پارامترها: اجتناب از انتساب به پارامترها
- جایگزینی متد با شیء متد: تبدیل یک متد به یک شیء
- جایگزینی الگوریتم: جایگزینی یک الگوریتم با یک الگوریتم واضحتر
با استفاده از این تکنیکها، میتوانید متدهایی ایجاد کنید که درک، استفاده مجدد و تغییر آنها آسانتر باشد و منجر به کدی قابل نگهداریتر و مقاومتر شود.
5. حرکت ویژگی: قرار دادن مسئولیتها به درستی
در بیشتر موارد، یک متد باید بر روی شیءای باشد که دادههای آن را استفاده میکند.
اصول شیءگرایی. برنامهنویسی شیءگرا درباره بستهبندی دادهها با رفتارهایی است که بر روی آن دادهها عمل میکنند. متدها باید بر روی شیءای قرار گیرند که مالک دادههایی هستند که استفاده میکنند. این اصل به ایجاد طراحی منسجمتر و قابل فهمتر کمک میکند.
حرکت متد. بازسازی حرکت متد شامل انتقال یک متد از یک کلاس به کلاس دیگر است. این کار معمولاً زمانی انجام میشود که یک متد بیشتر به دادههای کلاس دیگری علاقهمند باشد تا کلاسی که در حال حاضر در آن قرار دارد.
حرکت فیلد. بازسازی حرکت فیلد شامل انتقال یک فیلد از یک کلاس به کلاس دیگر است. این کار معمولاً زمانی انجام میشود که یک فیلد بیشتر به رفتار کلاس دیگری مرتبط باشد.
تکنیکهای دیگر حرکت ویژگی. سایر بازسازیها برای حرکت ویژگی شامل:
- استخراج کلاس: ایجاد یک کلاس جدید برای محصور کردن زیرمجموعهای از مسئولیتها
- درونخط کردن کلاس: ادغام یک کلاس به کلاس دیگر
- پنهان کردن واگذارنده: پنهان کردن جزئیات یک شیء واگذارنده
- حذف مرد میانه: حذف واگذاریهای غیرضروری
- معرفی متد خارجی: افزودن یک متد به کلاسی که نمیتوانید آن را تغییر دهید
- معرفی گسترش محلی: ایجاد یک کلاس جدید برای گسترش کلاسی که نمیتوانید آن را تغییر دهید
با استفاده از این تکنیکها، میتوانید اطمینان حاصل کنید که متدها و دادهها بر روی اشیاءای قرار میگیرند که برای آنها مناسبتر هستند و منجر به طراحی منسجمتر و قابل فهمتر میشود.
6. سازماندهی داده: ساختاردهی برای وضوح
کد خوب باید به وضوح آنچه را که انجام میدهد، ارتباط برقرار کند و نامهای متغیر کلید کد واضح هستند.
داده به عنوان اشیاء. دادهها باید به عنوان اشیاء در نظر گرفته شوند، نه فقط نوعهای اولیه. این به معنای محصور کردن دادهها با رفتار و ایجاد اشیائی است که مفاهیم معنادار را نمایندگی میکنند.
بازسازیها برای سازماندهی داده:
- خود محصور کردن فیلد: دسترسی به فیلدها از طریق دسترسیکنندهها
- جایگزینی مقدار داده با شیء: تبدیل یک مقدار داده به یک شیء
- تغییر مقدار به مرجع: تبدیل یک شیء مقدار به یک شیء مرجع
- تغییر مرجع به مقدار: تبدیل یک شیء مرجع به یک شیء مقدار
- جایگزینی آرایه با شیء: جایگزینی یک آرایه با یک شیء
- تکرار دادههای مشاهدهشده: تکرار دادهها برای همگامسازی
- تغییر ارتباط یکطرفه به دوطرفه: افزودن یک اشارهگر بازگشتی
- تغییر ارتباط دوطرفه به یکطرفه: حذف یک اشارهگر بازگشتی
- جایگزینی عدد جادویی با ثابت نمادین: جایگزینی عددهای جادویی با ثابتها
- محصور کردن فیلد: خصوصی کردن یک فیلد و ارائه دسترسیکنندهها
- محصور کردن مجموعه: بازگرداندن نمای فقط خواندنی از یک مجموعه
- جایگزینی رکورد با کلاس داده: تبدیل یک رکورد به یک کلاس داده
- جایگزینی کد نوع با کلاس: جایگزینی یک کد نوع با یک کلاس
- جایگزینی کد نوع با زیرکلاسها: جایگزینی یک کد نوع با زیرکلاسها
- جایگزینی کد نوع با حالت/استراتژی: جایگزینی یک کد نوع با یک شیء حالت
با استفاده از این تکنیکها، میتوانید ساختارهای دادهای ایجاد کنید که معنادارتر، آسانتر برای درک و مقاومتر در برابر تغییر باشند.
7. سادهسازی شرطی: شفافسازی منطق
وقتی متوجه میشوید که باید ویژگیای به یک برنامه اضافه کنید و کد برنامه به گونهای ساختار نیافته است که افزودن ویژگی آسان باشد، ابتدا برنامه را بازسازی کنید تا افزودن ویژگی آسان شود، سپس ویژگی را اضافه کنید.
منطق شرطی واضح. منطق شرطی میتواند به سرعت پیچیده و دشوار برای درک شود. مهم است که عبارات شرطی را ساده کنید تا خوانایی و نگهداری آنها آسانتر شود.
بازسازیها برای سادهسازی شرطی:
- تجزیه شرطی: شکستن یک شرط به متدهای کوچکتر
- ادغام عبارات شرطی: ترکیب چندین شرط به یک شرط
- ادغام قطعات شرطی تکراری: حذف کد تکراری در شاخههای شرطی
- حذف پرچم کنترل: جایگزینی پرچمهای کنترل با عبارات break یا return
- جایگزینی شرط تو در تو با بندهای نگهبان: استفاده از بندهای نگهبان برای موارد خاص
- جایگزینی شرط با چندریختی: استفاده از چندریختی برای مدیریت رفتار شرطی
- معرفی شیء تهی: جایگزینی بررسیهای تهی با یک شیء تهی
- معرفی تأیید: صریح کردن فرضیات با تأییدها
با استفاده از این تکنیکها، میتوانید منطق شرطی ایجاد کنید که درک، تغییر و نگهداری آن آسانتر باشد و منجر به کدی مقاومتر و قابل اعتمادتر شود.
8. پالایش رابط: سادهسازی تعاملات
کلید اینجا طول متد نیست بلکه فاصله معنایی بین آنچه متد انجام میدهد و چگونگی انجام آن است.
رابطهای واضح و مختصر. رابطها باید واضح، مختصر و آسان برای استفاده باشند. آنها باید هدف متدها را ارتباط برقرار کرده و تعامل با شیء را برای مشتریان آسان کنند.
بازسازیها برای پالایش رابط:
- تغییر نام متد: تغییر نام یک متد برای بهتر منعکس کردن هدف آن
- افزودن پارامتر: افزودن یک پارامتر به یک متد
- حذف پارامتر: حذف یک پارامتر از یک متد
- جداسازی پرسش از تغییر دهنده: جداسازی متدهایی که یک مقدار را برمیگردانند از آنهایی که وضعیت را تغییر میدهند
- پارامترسازی متد: ترکیب متدهای مشابه به یک متد با یک پارامتر
- جایگزینی پارامتر با متد صریح: ایجاد متدهای جداگانه برای هر مقدار پارامتر
- حفظ شیء کامل: ارسال کل شیء به جای مقادیر فردی
- جایگزینی پارامتر با فراخوانی متد: جایگزینی یک پارامتر با یک فراخوانی متد
- معرفی شیء پارامتر: جایگزینی چندین پارامتر با یک شیء
- حذف متد تنظیم: حذف یک متد تنظیم برای یک فیلد
- پنهان کردن متد: خصوصی کردن یک متد
- جایگزینی سازنده با متد کارخانه: جایگزینی یک سازنده با یک متد کارخانه
- محصور کردن تبدیل به پایین: انتقال تبدیلها به داخل متد
- جایگزینی کد خطا با استثنا: جایگزینی کدهای خطا با استثناها
- جایگزینی استثنا با تست: جایگزینی استثناها با تستهای شرطی
با استفاده از این تکنیکها، میتوانید رابطهایی ایجاد کنید که درک، استفاده و نگهداری آنها آسانتر باشد و منجر به کدی انعطافپذیرتر و مقاومتر شود.
9. عمومیسازی: استفاده مؤثر از وراثت
الگوهای طراحی اهدافی برای بازسازیهای شما فراهم میکنند.
استفاده مؤثر از وراثت. وراثت ابزاری قدرتمند برای استفاده مجدد از کد و چندریختی است، اما باید با احتیاط استفاده شود. مهم است که اطمینان حاصل کنید که زیرکلاسها واقعاً زیرنوعهای سوپرکلاسهای خود هستند و تنها رفتارهای مرتبط با خود را به ارث میبرند.
بازسازیها برای عمومیسازی:
- بالا کشیدن فیلد: انتقال یک فیلد به سوپرکلاس
- بالا کشیدن متد: انتقال یک متد به سوپرکلاس
- بالا کشیدن بدنه سازنده: انتقال منطق سازنده به سوپرکلاس
- پایین کشیدن متد: انتقال یک متد به زیرکلاس
- پایین کشیدن فیلد: انتقال یک فیلد به زیرکلاس
- ایجاد متد الگو: ایجاد یک متد الگو در سوپرکلاس
- استخراج زیرکلاس: ایجاد یک زیرکلاس جدید
- استخراج سوپرکلاس: ایجاد یک سوپرکلاس جدید
- استخراج رابط: ایجاد یک رابط جدید
- ادغام سلسلهمراتب: ادغام یک سوپرکلاس و زیرکلاس
- جایگزینی وراثت با واگذاری: جایگزینی وراثت با واگذاری
- جایگزینی واگذاری با وراثت: جایگزینی واگذاری با وراثت
با استفاده از این تکنیکها، میتوانید سلسلهمراتب وراثتی ایجاد کنید که انعطافپذیرتر، قابل نگهداریتر و آسانتر برای درک باشد.
10. بازسازیهای بزرگ: تحول سیستمهای کامل
مهمترین درس از این مثال، ریتم بازسازی است: تست، تغییر کوچک، تست، تغییر کوچک، تست، تغییر کوچک. این ریتم است که اجازه میدهد بازسازی به سرعت و ایمنی پیش برود.
تغییرات بزرگمقیاس. بازسازیهای بزرگ تغییر
آخرین بهروزرسانی::
FAQ
What's Refactoring: Improving the Design of Existing Code by Martin Fowler about?
- Focus on Code Improvement: The book is centered on refactoring, which involves restructuring existing code to enhance its internal structure without changing its external behavior.
- Practical Techniques: It offers a catalog of over seventy refactorings, each with detailed instructions and examples, making it practical for developers to apply in real-world scenarios.
- Target Audience: Aimed at professional programmers, it serves as a guide for improving coding practices and software design.
Why should I read Refactoring: Improving the Design of Existing Code by Martin Fowler?
- Enhance Code Quality: The book provides insights into improving code design, making it easier to maintain and extend, which is crucial for long-term projects.
- Learn Proven Techniques: It offers structured, real-world-tested refactoring techniques that can boost productivity and coding confidence.
- Avoid Common Pitfalls: By identifying "bad smells" in code, it helps developers proactively refactor before issues become unmanageable.
What are the key takeaways of Refactoring: Improving the Design of Existing Code by Martin Fowler?
- Refactoring is Essential: It is a necessary part of software development to prevent code decay and maintain design integrity.
- Small Steps Matter: Advocates for incremental changes to minimize bugs and track changes easily.
- Testing is Crucial: A robust suite of tests is essential to ensure consistent code behavior during refactoring.
How does Refactoring: Improving the Design of Existing Code by Martin Fowler define refactoring?
- Definition of Refactoring: It is the process of changing a software system to improve its internal structure without altering its external behavior.
- Purpose of Refactoring: Aims to make code easier to understand and modify, leading to better software quality.
- Continuous Process: Refactoring should be integrated into regular development practices to maintain code quality over time.
What are "bad smells" in code as described in Refactoring: Improving the Design of Existing Code by Martin Fowler?
- Indicators of Problems: "Bad smells" are symptoms in the code that suggest deeper issues, such as duplicated code or long methods.
- Common Examples: Includes "Duplicated Code," "Long Method," and "Feature Envy," each indicating a need for refactoring.
- Actionable Insights: Provides specific refactorings to address each type of bad smell, improving code clarity and maintainability.
What is the "Rule of Three" in Refactoring: Improving the Design of Existing Code by Martin Fowler?
- Guideline for Refactoring: Suggests refactoring after the third instance of similar code to prevent duplication from becoming a larger issue.
- Encourages Proactive Refactoring: Promotes maintaining clean and manageable code by being proactive about refactoring.
- Practical Application: Helps developers reduce technical debt by maintaining a cleaner codebase.
What are some common refactorings mentioned in Refactoring: Improving the Design of Existing Code by Martin Fowler?
- Extract Method: Involves creating a separate method from a section of code to improve readability and reusability.
- Inline Method: Opposite of Extract Method, where a method's body is replaced with its calls to simplify the code.
- Move Method: Used when a method is more relevant to another class, improving code organization and responsibilities.
How does testing play a role in refactoring according to Refactoring: Improving the Design of Existing Code by Martin Fowler?
- Foundation for Refactoring: A solid suite of tests is essential to ensure consistent code behavior during refactoring.
- Self-Testing Code: Advocates for writing self-testing code to automatically verify expected behavior after changes.
- Continuous Testing: Encourages frequent testing to catch issues early, leading to more reliable and maintainable code.
What is the significance of "Encapsulate Field" in Refactoring: Improving the Design of Existing Code by Martin Fowler?
- Improves Data Access: Involves creating getter and setter methods for a field to maintain data integrity.
- Facilitates Future Changes: Allows changing the internal data representation without affecting external code.
- Promotes Good Design Practices: Encapsulation is a fundamental principle of object-oriented design, reducing class coupling.
What are some best practices for refactoring as outlined in Refactoring: Improving the Design of Existing Code by Martin Fowler?
- Take Small Steps: Emphasizes making small, incremental changes to minimize bugs and track changes easily.
- Test Frequently: Run tests after each small change to ensure consistent code behavior and catch issues early.
- Focus on Readability: Refactor to make code more understandable, leading to better maintainability and collaboration.
What are the best quotes from Refactoring: Improving the Design of Existing Code by Martin Fowler and what do they mean?
- "Code is like humor. When you have to explain it, it’s bad.": Stresses the importance of writing clear, understandable code.
- "Refactoring is a controlled technique for improving the design of an existing code base.": Highlights refactoring as a systematic approach to enhance code quality.
- "The best time to refactor is when you are adding a feature.": Suggests integrating refactoring into the development process to maintain clean and efficient code.
How can I apply the concepts from Refactoring: Improving the Design of Existing Code by Martin Fowler in my projects?
- Start Small: Begin with simple refactorings in current projects, focusing on one or two techniques at a time.
- Incorporate Refactoring into Workflow: Make it a regular part of development, such as during code reviews or when adding features.
- Encourage Team Collaboration: Share concepts and techniques with your team for better code quality and shared understanding.
نقد و بررسی
کتاب بازنویسی کد بهعنوان یک منبع ضروری برای توسعهدهندگان نرمافزار شناخته میشود و تکنیکهای عملی برای بهبود کیفیت کد ارائه میدهد. خوانندگان از توضیحات شفاف، مثالهای جاوااسکریپت و فهرست بازنویسیها قدردانی میکنند. بسیاری این کتاب را بهعنوان یک راهنمای مرجع در طول دوران حرفهای خود مفید میدانند. برخی به محتوای قدیمی در نسخههای قبلی و مشکلات کیفیت کاغذ انتقاد کردهاند. در حالی که توسعهدهندگان با تجربه ممکن است اطلاعات جدید کمتری پیدا کنند، اکثر آنها بر این باورند که این کتاب برای درک و بهکارگیری اصول بازنویسی ارزشمند است. این کتاب بر تغییرات تدریجی، فرآیندهای کنترلشده و تطبیق تکنیکهای بازنویسی با زمینههای خاص تأکید میکند.
Similar Books







