Buy new:
$48.99$48.99
Arrives:
Thursday, Nov 9
Ships from: Amazon.com Sold by: Amazon.com
Buy used: $41.70
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required.
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera - scan the code below and download the Kindle app.
Working Effectively with Legacy Code 1st Edition
| Price | New from | Used from |
- Kindle
$37.99 Read with our free app - Paperback
$41.70 - $48.9925 Used from $23.34 17 New from $48.98
Purchase options and add-ons
This book provides programmers with the ability to cost effectively handlecommon legacy code problems without having to go through the hugelyexpensive task of rewriting all existing code. It describes a series of practicalstrategies that developers can employ to bring their existing softwareapplications under control. The author provides useful guidance about how touse these strategies when refactoring or making functional changes to codebases. One of the book's key points is that it teaches developers to write teststhat can be used to make sure they are not unintentionally changing theapplication as they optimize it. Examples are provided in Java, C++, and Csharp,and the book assumes that the reader has some knowledge of UMLnotation. Strategies using UML and code in C++ and Java primarily whilelanguage independent advice will be delivered in side bars and appendices forlanguage specific users.
- ISBN-100131177052
- ISBN-13978-0131177055
- Edition1st
- Publication dateSeptember 22, 2004
- LanguageEnglish
- Dimensions7 x 1.2 x 9.25 inches
- Print length464 pages
Frequently bought together

More items to explore
The Pragmatic Programmer: Your Journey To Mastery, 20th Anniversary Edition (2nd Edition)David ThomasHardcover$10.24 shipping
Mythical Man-Month, The: Essays on Software Engineering, Anniversary EditionFrederick Brooks Jr.Paperback$9.66 shipping
From the brand
From the Publisher
Must-Read for Every Programmer and Developer
This classic, endorsed by Robert "Uncle Bob" Martin (author of Clean Code), is on many must-read lists for programmers and developers including lists featured on Guru99, DZone, Built In, Dev Community (dev.to), and more.
"The book is important, as almost every developer at some point in career, has to work with a legacy system and it still represents the most challenging problems for many companies. The book goes deep into understanding the general process of a software change like adding features, fixing bugs, optimizing performances, etc."
—Milan Milanovic, DZone, November 2021
Editorial Reviews
From the Back Cover
Get more out of your legacy systems: more performance, functionality, reliability, and manageability
Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.
In this book, Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases. This book draws on material Michael created for his renowned Object Mentor seminars: techniques Michael has used in mentoring to help hundreds of developers, technical managers, and testers bring their legacy systems under control.
The topics covered include
- Understanding the mechanics of software change: adding features, fixing bugs, improving design, optimizing performance
- Getting legacy code into a test harness
- Writing tests that protect you against introducing new problems
- Techniques that can be used with any language or platform―with examples in Java, C++, C, and C#
- Accurately identifying where code changes need to be made
- Coping with legacy systems that aren't object-oriented
- Handling applications that don't seem to have any structure
This book also includes a catalog of twenty-four dependency-breaking techniques that help you work with program elements in isolation and make safer changes.
© Copyright Pearson Education. All rights reserved.
About the Author
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.
Product details
- Publisher : Pearson; 1st edition (September 22, 2004)
- Language : English
- Paperback : 464 pages
- ISBN-10 : 0131177052
- ISBN-13 : 978-0131177055
- Item Weight : 1.63 pounds
- Dimensions : 7 x 1.2 x 9.25 inches
- Best Sellers Rank: #59,841 in Books (See Top 100 in Books)
- #9 in Software Design & Engineering
- #19 in Software Testing
- #70 in Software Development (Books)
- Customer Reviews:
Important information
To report an issue with this product, click here.
About the author

Discover more of the author’s books, see similar authors, read author blogs and more
Customer reviews
Customer Reviews, including Product Star Ratings help customers to learn more about the product and decide whether it is the right product for them.
To calculate the overall star rating and percentage breakdown by star, we don’t use a simple average. Instead, our system considers things like how recent a review is and if the reviewer bought the item on Amazon. It also analyzed reviews to verify trustworthiness.
Learn more how customers reviews work on AmazonReviews with images
Submit a report
- Harassment, profanity
- Spam, advertisement, promotions
- Given in exchange for cash, discounts
Sorry, there was an error
Please try again later.-
Top reviews
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
Having not known anything other than this one project for my entire career, and not having a college or professional work culture that ever pushed testing on us (until now), it was kind of eerie to read through this book and find seemingly endless examples of the issues and challenges that obstruct my normal work every single day. I feel like I understand better now why some people are adamant about testing, it would have made a huge difference in what it's like to work on this legacy project of ours today, if it had been a priority way back when.
It is also evident to me however after reading the book that testing is not like some magic bullet, either, and just sprinkling some tests around doesn't fix problems like the ones I face. The author comes off a bit over-excited about how unit tests could change your life (paraphrasing), and he is right, but you have to put in the actual work. I would describe it like getting hooked by one of those old Bowflex TV commercials and so you get the workout equipment and then realize "wow, I am going to have to do a lot of work to get the results I want", and then this book is at least trying to be your workout guide on what muscle groups you should be exercising and roughly how to do it. Pretty useful but you still have to put it all together yourself into a routine that is right for you/your team/your project, and then actually do the work, continuously. Reading this book and then not applying the advice within will get you about the same results as reading a book about workouts and exercise for a healthy body and then continuing to not exercise and eating fast food for lunch every day.
I think in my case after working in real-life examples of whats in this book for over a decade very little of it surprised me in any way, but it was helpful to see these things spelled out with their cause and effect, ideas for solutions, how to at least avoid making the problem worse, etc.
I understand now why some people we would hire as new developers to the project would get all sad and disappointed when they asked about tests and we told them we really don't have any. I literally never knew any better and wasn't convinced until I read this book.
So I would say that all devs/engineers should read this book at least once, there is value in it for sure. On the downside, prepare yourself for a difficult and dull slog. The book, for all its wisdom within, is not particularly engaging to read and the examples are just. plain. awful. Truthfully even if I had read this book 10+ years ago when I was getting started, I'm not sure the examples would have spoke to me (because they are terrible), which might have made it less convincing. But it was the case that at the time I read this I had been working and playing with live examples for a decade-plus as I said before so all the examples he described were perfectly apparent to me in my own project's code. His examples stink.
I think it would help newer developers if there was a digital copy that you could provide some parameters and get examples in only a language that is familiar to you. That and also re-write all the examples to not stink somehow. I don't know, the examples are hyper-realistic in the sense that "yeah, I have definitely seen people write garbage like this all the time," but the things he is trying to demonstrate in these examples don't have to be made more realistic by using awful naming, spacing, lack of comments, etc. Just my personal opinion.
It is a difficult book to force yourself to keep reading through, in my opinion, but you definitely should and you will most likely be glad you did.
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.
Once I had to work with a program that consisted of one huge class. About 6000 lines of code, hundreds of variables. What kind of dependency breaking techniques would you use on a program that has no dependencies because it has no components? How would you deal with three almost identical tabs in the GUI, which don't correspond to instances of one class, but rather to subsets of fields named like "button1", "textField1" (first tab), "button2", "textField2" (second tab)? How would you go about refactoring code that uses fields to pass data from one method to another? How do you work with code that excessively abuses macros in C/C++, like "#define true false" or "#define begin {" / "#define end }"? And how on Earth would you work with a program that has three global variables named L, LL and LLL that are used for dozens of similar yet slightly different purposes throughout the codebase? This book has no answers. But then again, I suspects that nobody does.
This book is mainly about refactoring messy but refactorable code in the least risky way just to get enough test to be able to change more. It's an excellent book as far as this narrow topic goes, but don't expect it to be much more than that.
Top reviews from other countries
Feathers' thesis, subsequently elaborated in several lectures available on YouTube, is powerful: when one has difficulty writing automated tests for a codebase, it is an indication that the codebase itself is not well-factored.
Quite often, I have heard developers complain how difficult it is to write tests for a piece of code, and then use that as an excuse to avoid writing the tests. Feathers gives us another way of seeing this situation: the characteristics that make code testable are themselves characteristics of good code. Testability requires composability, reusability, etc., so problems encountered writing tests very often come from a design flaw in the code itself.
Thankfully, this book doesn't leave us hanging at "my code is horrible because it's hard to test." Instead, most of the book is filled with realistic examples that demonstrate patterns for refactoring code to bring it under test. The examples are simple and easy to follow. They're also quite on-point: I recall reading many of them and thinking "yep, I hate it when I have that problem."
Though each example is approached from the perspective of someone trying to solve a specific testability issue, the refactoring techniques taught by the examples are applicable to more situations than merely getting code under test. In this book, Feathers isn't just teaching how to get a piece of code under test, he is teaching how to take a piece of code and incrementally move it towards a better design that actually does what you need it to do.
This book describes common, real-world problems and shows simple solutions to those problems. The examples feel concrete and familiar, not contrived like the examples in so many design patterns books. It is written in clear, accessible language, and is not boring to read. I believe that this book will make anyone who reads it a better programmer.
Very large applications will:
* contain millions of lines of code
* have been in production for years
* have been worked on by dozens of developers, with varying degrees of competence
* have many bugs
* be so big that nobody fully understands them
* be difficult to change - a seemingly small change could introduce serious bugs
If you find yourself working on such a beast, what can you do? I suggest that you take a long hard look at this book. It will give you confidence, knowing that you’re not alone.
After introductory material, it’s organised into a list of problems/FAQS and solutions/patterns which are heavily interlinked. Example: I don’t have much time and I have to change it => sprout method, sprout class, wrap method, and wrap class. Wrap class itself refers to extract implementer, extract interface, and decorator pattern.
You’d probably go mad or become dispirited if you read all of the book sequentially. I recommend that you read the first, easy sections; skim the rest so that you get an overview of the contents; then use it in anger when you have a real problem to solve. The techniques you actually use then become part of your armoury for the future.
Without these techniques it can be soul-destroying to work on “legacy” applications. With the techniques you stand a chance of transforming the situation into being comfortable and maybe even enjoyable - because you’re applying engineering techniques to make valuable applications even more valuable.
I wish I'd found Michael's book earlier, it would have helped ease the transition. Of course, not everyone else's code is legacy code, but even if you are not handling true 'legacy' code, this book will help you deal with the problems you face.
The book is in three parts. The first is a discussion of how you go about changing software that is badly structured and has complex interactions and side effects. Where do you start, and how do you make sure that you don't break things further down the convoluted chain of dependencies. The answer to the latter, of course, is testing, testing, testing, and the author makes a good enough case to persuade even the most sloth like to get into the testing mode.
The second part of the book is organised almost like an FAQ with chapters devoted to common problems like 'I don't understand the code well enough to change it'. This one crops up all too often, and is an excellent example of how the author doesn't avoid difficult questions. The final part of the book is a useful catalog of mostly pattern based techniques that can be used to break dependencies.
The book is well written and features clear examples that are written in either C++, Java, C and C#, and the problems caused by the different features, or lack of them, available to the different languages are discussed and work arounds suggested. I enjoyed reading this book.
Highly recommended!
Il contenuto è ovviamente ottimo, anche se i tools di refactoring odierni lo rendono in qualche parte superato.
Reviewed in Italy on February 21, 2022
Il contenuto è ovviamente ottimo, anche se i tools di refactoring odierni lo rendono in qualche parte superato.












