Working Effectively with Legacy Code
برچسب ها:
Design Patterns |Test Driven Development |Coding |Refactoring |
Prentice Hall
Michael Feathers
978-0131177055
2004
464
English
در صنعت، اغلب از Legacy Code به عنوان اصطلاحی برای کدی که تغییرش سخت است و ما آن را نمی‌فهمیم استفاده می‌شود. اما من پس از سال‌ها کار با تیم‌های مختلف و کمک کردن به آن‌ها در رفع کردن مشکلات جدی کد هایشان، به تعریف متفاوتی دست یافتم.
از نظر من Legacy Code، کدی است که فاقد تست است. چند دلیل نیز برای این تعریف خودم دارم. تست‌ها چه ربطی به بد بودن کد دارند؟ از نظر من پاسخ بدیهی است و این نکته ای است که در این کتاب می‌خواهم آن را بیان کنم:
کد بدون تست، کد بدی است. اهمیتی ندارد که چقدر خوب نوشته شده باشد یا چقدر زیبا و شی گرا یا به خوبی کپسوله سازی شده باشد. با داشتن تست‌ها است که ما می‌توانیم رفتار کد را به سرعت و به طرز صحیحی تغییر دهیم. بدون آن‌ها ما واقعا نمی‌دانیم که آیا کد بهتر شده یا بدتر شده است.
The topics covered include
o Understanding the mechanics of software change: adding features, fixing bugs, improving design, optimizing performance
o Getting legacy code into a test harness
o Writing tests that protect you against introducing new problems
o Techniques that can be used with any language or platformwith examples in Java, C++, C, and C#
o Accurately identifying where code changes need to be made
o Coping with legacy systems that aren't object-oriented
o Handling applications that don't seem to have any structure
Table of Contents
1. Title Page
2. Copyright Page
3. Contents
4. Foreword
5. Preface
6. Introduction
7. Part I: The Mechanics of Change
1. Chapter 1: Changing Software
2. Chapter 2: Working with Feedback
3. Chapter 3: Sensing and Separation
4. Chapter 4: The Seam Model
5. Chapter 5: Tools
8. Part II: Changing Software
1. Chapter 6: I Don’t Have Much Time and I Have to Change It
2. Chapter 7: It Takes Forever to Make a Change
3. Chapter 8: How Do I Add a Feature?
4. Chapter 9: I Can’t Get This Class into a Test Harness
5. Chapter 10: I Can’t Run This Method in a Test Harness
6. Chapter 11: I Need to Make a Change. What Methods Should I Test?
7. Chapter 12: I Need to Make Many Changes in One Area. Do I Have to Break Dependencies for All the Classes Involved?
8. Chapter 13: I Need to Make a Change, but I Don’t Know What Tests to Write
9. Chapter 14: Dependencies on Libraries Are Killing Me
10. Chapter 15: My Application Is All API Calls
11. Chapter 16: I Don’t Understand the Code Well Enough to Change It
12. Chapter 17: My Application Has No Structure
13. Chapter 18: My Test Code Is in the Way
14. Chapter 19: My Project Is Not Object Oriented. How Do I Make Safe Changes?
15. Chapter 20: This Class Is Too Big and I Don’t Want It to Get Any Bigger
16. Chapter 21: I’m Changing the Same Code All Over the Place
17. Chapter 22: I Need to Change a Monster Method and I Can’t Write Tests for It
18. Chapter 23: How Do I Know That I’m Not Breaking Anything?
19. Chapter 24: We Feel Overwhelmed. It Isn’t Going to Get Any Better
9. Part III: Dependency-Breaking Techniques
1. Chapter 25: Dependency-Breaking Techniques
10. Appendix: Refactoring
11. Glossary
12. Index
می پسندم
به درد نمی خوره
