- 出版社: Prentice Hall; 1 (2004年10月2日)
- 丛书名: Robert C. Martin Series
- 平装: 456页
- 语种： 英语
- ISBN: 0131177052
- 条形码: 0076092025986, 9780131177055
- 商品尺寸: 17.5 x 2.8 x 22.6 cm
- 商品重量: 726 g
- ASIN: 0131177052
- 用户评分: 分享我的评价
- 亚马逊热销商品排名: 图书商品里排第773,329名 (查看图书商品销售排行榜)
Working Effectively with Legacy Code (英语) 平装 – 2004年10月2日
MICHAEL C. FEATHERS works for Object Mentor, Inc., one of the world's top providers of mentoring, skill development, knowledge transfer, and leadership services in software development. He currently provides worldwide training and mentoring in Test-Driven Development (TDD), Refactoring, OO Design, Java, C#, C++, and Extreme Programming (XP). Michael is the original author of CppUnit, a C++ port of the JUnit testing framework, and FitCpp, a C++ port of the FIT integrated-testing framework. A member of ACM and IEEE, he has chaired CodeFest at three OOPSLA conferences.
© Copyright Pearson Education. All rights reserved.
I. THE MECHANICS OF CHANGE.
1. Changing Software.
2. Working with Feedback.
3. Sensing and Separation.
4. The Seam Model.
II. CHANGING SOFTWARE.
6. I Don’t Have Much Time and I Have To Change It.
7. It Takes Forever To Make a Change.
8. How Do I Add a Feature?
9. I Can’t Get This Class into a Test Harness.
10. I Can’t Run This Method into a Test Harness.
11. I Need to Make a Change. What Methods Should I Test?
12. I Need to Make Many Changes In One Area Do I Have To Break.
13. I Need To Make a Change but I Don’t Know What Tests To Write.
14. Dependencies on Libraries Are Killing Me.
15. My Application Is All API Calls.
16. I Don’t Understand the Code Well Enough To Change It.
17. My Application Has No Structure.
18. My Test Code Is in the Way.
19. My Project Is Not Object-Oriented. How Do I Make Safe Changes?
20. This Class Is Too Big and I Don’t Want It to Get Any Bigger.
21. I’m Changing The Same Code All Over the Place.
22. I Need To Change a Monster Method and I Can’t Write Tests for It.
23. How Do I Know That I’m Not Breaking Anything?
24. We Feel Overwhelmed. It Isn’t Going To Get Any Better.
III. DEPENDENCY BREAKING TECHNIQUES.
25. Dependency Breaking Techniques.
|5 星 (0%)|
|4 星 (0%)|
|3 星 (0%)|
|2 星 (0%)|
|1 星 (0%)|
The only flaw in this book is: It doesn't go far enough. I've now been working for 1+yr with a 20+yr old C++ code base (that's still responsible for over $1B revenue a year, runs on over 1500 servers, handles well over 100000 requests/min in total). I read this book in the first couple of weeks and thought "yeah, ok, but things can't possibly be that bad".
Well, now I know better. They're worse.
This book can help you _a lot_ with the technical aspects of working with legacy code - but some things (esp. long-standing company processes) just can't be fixed by mortal man. So you need a good attitude (including a good sense of humor) as well. Working with good colleagues also helps. But definitely read this book and use its lessons in practice.
Is your code a tangled mess? Are you tired of seeing telescoping methods and methods that are 100s of lines long? Want to clean up code you didn't write and get it under test but everyone's too afraid of breaking things? Does it take you forever to write unit tests? Is it painstaking and laborious? Do you write mainly integration tests because unit testing is too hard? Do you wonder how people can write lots of unit tests, let alone unit test every method? Do you want to kick your object oriented coding skills up a notch? Then this book is for you. It can teach you how to overcome all of those obstacles and so much more.
For me the first roughly 100 pages of the book were a revelation. If you don't understand how to do TDD the problem probably isn't testing, it's probably the code you're trying to test or your perceptions about what it is that you are actually supposed to be testing. Michael Feathers does a great job identifying the mistakes and traps that so many developers experience when trying write and test good code and provides recipes for overcoming them. He adds clarity to what a unit test is and what it's supposed to do and in the process takes a deep dive into what good object oriented code looks like through the eyes of TDD. The book can completely change your perception about what is and is not possible.
In addition to turning your perceptions about testing on their head, Feathers also provides good advice on how to create loosely coupled code, how to identify and eliminate dependencies in existing code as well as strategies for reorganizing poorly structured code into better objects. This book has clearly changed the way I code and the way I think about testing for the better. It's not just about testing it's also about turning procedural code into object oriented code and bringing your object oriented thinking to the next level.
I can't say enough great things about this book. It's dearer to me than any other book in my programming collection including books about object oriented code from Bloch, Beck, Fowler and others. It wasn't until I read Working Effectively with Legacy Code that things really came together for me in the object oriented world. I got the concepts individually but failed to recognize how it all comes together. What's so great about encapsulation / getters and setter? Why is it so important to have classes and methods that do just one thing? What's so important about breaking dependencies between classes? How small is a small method? How can I ever hope to achieve open/closed? How is TDD even possible? Your mileage may vary, but if you're like me this book will change your life for the better.
Some of Michael's techniques are old friends that I never thought to use in this way. Others were things I didn't realize I knew at all, and others were totally new to me. What they all had in common was that they offer a wealth of approaches to incrementally improve a tough situation, both to accomplish the immediate task and to prepare for further improvements later. This pay-as-you go alternative is both more effective and less risky than either of the extremes of doing nothing or large-scale replacement.
Another strength of the book is that Mr. Feathers provides examples in several languages, mostly Java and C++, but also Ruby and some others. This variety is very helpful for deepening our understanding of both the problems and the solutions.
There are two main points in this book:
1. Legacy code is anything without unit tests.
2. Step one of working with legacy code is to write unit tests.
There is more than that, but my point in sharing this is that the author clearly knows the right approach. It is still a good read even if the book is old. However, this is not expert-level material: if you already have experience in this area, this book might teach you a trick or two but you should already know most of what is in here.