118 of 121 people found the following review helpful
on October 20, 2004
The average book on Agile software development describes a fairyland of greenfield projects, with wall-to-wall tests that run after every few edits, and clean & simple source code.
The average software project, in our industry, was written under some aspect of code-and-fix, and without automated unit tests. And we can't just throw this code away; it represents a significant effort debugging and maintaining. It contains many latent requirements decisions. Just as Agile processes are incremental, Agile adoption must be incremental too. No more throwing away code just because it looked at us funny.
Mike begins his book with a very diplomatic definition of "Legacy". I'l skip ahead to the undiplomatic version: Legacy code is code without unit tests.
Before cleaning that code up, and before adding new features and removing bugs, such code must be de-legacified. It needs unit tests.
To add unit tests, you must change the code. To change the code, you need unit tests to show how safe your change was.
The core of the book is a cookbook of recipes to conduct various careful attacks. Each presents a particular problem, and a relatively safe way to migrate the code towards tests.
Code undergoing this migration will begin to experience the benefits of unit tests, and these benefits will incrementally make new tests easier to write. These efforts will make aspects of a legacy codebase easy to change.
It's an unfortunate commentary on the state of our programming industry how much we need this book.
99 of 106 people found the following review helpful
on October 13, 2004
Martin Fowler's book on Refactoring showed us how to improve the design of our code. We learned to make changes safely, by taking small, rote steps, and by ensuring that we ran our tests after each small change. But what if we're working on the typical ugly system with no tests? In Working Effectively With Legacy Code, Michael Feathers tackles the problem that most of us end up dealing with.
Feathers does an excellent job of articulating the problems and scenarios, using clear examples from C, C++, Java, and C#. Many of the code examples look a lot like real examples I come across all the time--they don't appear to be fabricated.
Working Effectively With Legacy Code contains a catalog that provides a wealth of solutions. The catalog shows how to resolve concerns like, "I'm changing the same code all over the place" and "how do I safely change procedural code?"
The book is highly entertaining and comes across as a conversation with a really sharp, really patient guru developer. Often, it's a chore to slog through code-heavy books. But Feathers manages to keep my attention with interesting stories, loads of examples, and well-written text.
I think that Working Effectively With Legacy Code is an important book. The vast majority of existing code presents the classic catch-22: you can't change it safely because it doesn't have tests, and you can't write tests without changing it to easily support testing. It's not an easy problem, and most people will give you high-level ideas for solving it. Feathers is the first person to dig deep and present a wealth of knowledge and insight on the problem, all in one place. I'll be pulling this book from my shelf for years to come.
41 of 44 people found the following review helpful
on November 11, 2004
"Working Effectively with Legacy Code" is a very valuable resource. The author defines "legacy code" as "code without tests." It doesn't matter whether the code was written last week or ten years ago. There is more emphasis on old code that nobody understands, mainly because it is messier and harder to work with.
The examples in the book are mainly in C, C++ and Java, but there are a couple in C# and Ruby. While it is essential to know one of these languages, the author provides enough information to understand the others. When a technique only applies to a certain language, it is clearly indicated.
The author shows how different diagrams can help you learn how to understand code. In addition to UML, there are dependency and effect sketches. The author uses these to show how to think about understanding and refactoring. Other tools, such as refactoring browsers and mocks are explained.
Speaking of refactoring, there are "dependency breaking techniques" (aka refactorings) with step-by-step instructions (Martin Fowler style) throughout the book. There are also explanations of why patterns and design rules exist. Most importantly, there are lots and lots of cross-references and an excellent index.
Working with legacy code isn't fun, but this book helps make it as painless as possible. With the split emphasis between psychological/understanding/techniques and refactoring, this book is both a great read and an excellent reference.
100 of 114 people found the following review helpful
on December 3, 2009
I work at a decent sized telecommunications company. We have legacy code written in C that is over 1 million lines of code. Some of the code was written as far back as 1988. Needless to say, we didn't follow TDD and there are not a lot of unit tests. We have recently increase the number developers to add features to this code base and I was hoping that this book would help.
We've been doing a "techincal book club" for a while as part of continuous training. I've had about 20 engineers reading this book a few chapters a week and discussing them. Most of the reviews from the group have been negative. Hard to read, annoying editorial errors (duplicate text on following pages), and not really getting a lot out of it. The main problem is that our system is not using an object oriented language so a lot (most) of the techniques are not relevant.
At first I thought it was just me, but as I asked the other engineers, there was a lot of concensus, even from engineers that have worked on Java/C++ projects in the past.
I picked this book because of the following taglines on the back of the book:
* Techniques that can be used with any language or platform-with examples in Java, C++, C, and C#
* Coping with legacy systems that aren't object-oriented
There is one small section on non-object oriented code. It basically says that you should slowly migrate to an object oriented language.
Anyway - we've stopped reading the book. If you're code is already object oriented, this is probably a great book. If it's not, I wouldn't bother. Instead pick up a differnt book on how to migrate the code to an object oriented language.
16 of 17 people found the following review helpful
on July 27, 2008
I am an entry level software developer who has only been in the industry for a little over a year. While I was in college, I was always provided with very clean code bases to work with or analyze. I was in for a huge surprise when I entered the real world. The code I deal with every day at work is an extremely ugly mess. We have no automated tests. We are basically operating at CMMI level 0. There are no clear coding conventions of any kind. People just kind of band-aid things on top of other band-aids just to make the new changes work. We are basically in emergency mode every day because of all of the ugly side effects of global variables and functions. I was presented this book one day by my company news website. So I grabbed a copy and gave it a chance.
I was very satisfied with this book. I was expecting to start reading this and it would be like one of those GoF (Gang of Four) or Martin Fowler books that already assume that your code is already written fairly well in the first place. The reality is, like others have said here, is that most companies you will work for will just not have the prettiest code base in the world. The book's content is fabulous and I can see this being one of the key books on my desk every day. I absolutely love how pragmatic Michael Feathers is. I like how he continuously explains the concept that sometimes the code might look uglier or awkward in order to get it under test. I always thought the design pattern books were just a bit over the top. Michael is not like that. He provides examples you probably run into everyday and provides succinct steps for getting it under test.
The only gripe that I have with this book is the overwhelming amount of publishing errors throughout the book. Sometimes, a word is skipped in a sentence or the wrong word is obviously used. There was one point in the book I recall where it seemed like it was missing the ending of a sentence or something. I think if Michael ever wants another edition of this book then he ought to hire someone new that will catch all of these little glitches and correct them. They were a bit annoying at times. Also, like someone else said, it would've been nice to see some examples of really old code in COBOL or FORTRAN even.
Otherwise, it is easy to read this book and you'll get through it fairly quickly. There have been some technical books I have read where I just couldn't read it all the way through because of how utterly boring it was. Michael keeps you entertained with some rather interesting concepts and stories. I also like the way he formatted the book in general. I like how many of the chapters in the book are titled by some problem like "These API Calls Are Killing Me!" However, the last chapter called "Refactoring" was a bit vague and odd to me especially since all it discussed was his infamous "Extract Method" refactoring.
I really wish all of the developers on this team would read this book. They really need to. We need to stop this game of changing and guessing whether it worked. You just cannot do that with software unless it is very small. Any software engineer should have this book on their desk.
13 of 14 people found the following review helpful
on June 25, 2005
I've never read a technical book quite like this one. The author has distilled several years worth of experience into one highly cohesive and detailed book.
If you think you don't need this book because you aren't working on legacy code, think again. I recently joined a project that had only been going for a few months, and this book has been very valuable to me. This book helps recognize that many projects start off on the right foot and soon the code base turns into a quagmire. The advice here will help you turn it around, but it will not be easy even with this book.
Not only does it give solid advice for dealing with specific situations, it is written in a lively style that contrasts with the sometimes depressing work associated with maintenance.
The book is organized in a FAQ style, with chapters titled as questions. This makes it very easy to pickup and narrow down what part is relevant to your current situation. The final part includes a list of dependency breaking techniques designed to help you get code under test.
9 of 9 people found the following review helpful
on October 25, 2004
(Copy of a review found at [...])
If you need to fix, maintain or extend code without tests, and you're trying to do it without having a copy of this book by your side, you might as well just jab yourself in the stomach with a knife. Michael Feathers does for legacy code what the Gang of Four did for design: establish a vocabulary to make it easier to understand and communicate about how to work with legacy code.
There are some books that we use as references when we teach courses or do some consulting. These are usually the fundamental texts that provide an appropriate foundation for the reader in a given topic area: Java programming, programmer testing, enterprise architecture, what have you. Even before the book had been released, we were recommending it in courses on Test-Driven Development. The reason is clear: true greenfield projects are few and far between. A team trying to adopt Test-Driven Development has enough to learn; we can't leave them to their devices to figure out what they're going to do starting Monday. "How do we deal with the 250,000 lines of untested code we still need to use?" A Master Programmer cannot leave a team like that hanging.
Enter Michael Feathers and his years of experience rescuing legacy codebases. He has distilled his secrets into a collection of fundamental techniques combined with a catalog of strategies and approaches. In many ways, WELC is like other "how to" books: it starts with setting the context for the techniques, describes them with examples, then adds a catalog of ways to break dependencies in the back. One of the things that differentiates this book is the chapter titles. They are whimsical and, as a result, effective. Some examples follow.
* It Takes Forever to Make a Change
* I Need to Make Many Changes in One Area
* My Application Has No Structure
* This Class Is Too Big and I Don't Want It to Get Any Bigger
We have struggled with maintaining existing code, and in the process have had many of the exact complaints that Michael has made into chapter titles. Each chapter is rich with useful examples in Java, C# and C++. You'd be surprised how many requests we get for courses teaching Test-Driven Development in C++, and they have plenty of legacy code to work around! Michael's conversational style gives you the feeling of having him along side while you work, and frankly, you can't get Michael for only USD 45 plus taxes, but the book is a bargain at twice the price.
In order to add book reviews to this web site (masterprogrammer.info), we needed to add a feature to a small amount of legacy code in PHP. (We're still learning how to test-drive PHP-based web sites, so we've made the classic mistake of worrying about it later. See how easy it is?) We used techniques like Sprout Method to make safe changes to the code that generates our Self-Study bookshelf while adding the ability to link a book to our review. What more proof do you need? To purchase Michael's excellent book, go back to our Self-Study bookshelf and click on Working Effectively with Legacy Code.
16 of 18 people found the following review helpful
on August 12, 2011
The examples are very good, also the techniques. But, the way ideas are organized is completely crazy.For
the whole book there are references to techniques only explained on the LAST part.
For this reason, I was on the page 117 and gave up, and started to read the last chapter, and...
the first technique (adapt parameter), on page 325, says: "just use this technique if "extract
interface" doesn't work. But where is "extract interface"? ON PAGE 362!!!!!
So I went to page 362 and the text started saying that there are some tricks...the compiler
helps, there are many tools to implement, but: I want to know WHAT IS "extract interface",
and just in the middle of the chapter it is defined.
There are a lot of examples like this. I really liked the ideas, but in my opinion it is necessary some improvement on the way the ideas area organized.
30 of 37 people found the following review helpful
on June 2, 2008
This book is decent but it doesn't break much new ground. The author has the Fowler-esque affectation of naming very simple things to create a shared and clear vocabulary (ie making a change and seeing what it breaks when you compile is now the LeaningOnTheCompiler pattern) which feels a little overdone in places.
There was some good material here, but generally the best parts were where he would tie an example into a well known design principal which would be explained in a sidebar (SRP, etc). Of course, that kind of stuff could be found elsewhere in a more concise format.
The book is nice in that it makes you think through the samples, I just wish there were more moments after doing that where I went "oh hey, cool" (there were a couple, don't get me wrong) instead of "yeah, thats pretty much how we do it now".
23 of 28 people found the following review helpful
on January 3, 2005
The vast majority of software texts are about greenfield development: creating a new application from nothing at all. But the vast majority of software work involves existing code: adding features, finding bugs, or refactoring code that someone else wrote. This book is a supurb first step in fixing that imbalance.
This is not a theoretical work. For example, Feathers does not present a grand ontology of legacy systems. Not is this book heavy on methodology. Instead Feathers describes techniques --- lots of techniques, roughly 50 --- for working with legacy code.
The techniques are organized by the problems they address. For example, one chapter is entitled "My Application Is All API Calls" and then presents two techniques for working with existing code that is full of calls to APIs.
Feathers comes from the XP school, and he adopts that school's premise that you can safely change code if (and only if) there are sufficient tests in place to tell you when your new change has introduced a bug. Many of the techniques in this book are about different ways of putting legacy code into test harnesses, and doing that safely without introducing bugs along the way.
He also introduces new concepts, or at least concepts I had never seen before. For example, a "characterization test" is a test that characterizes the actual behavior of the code, not what the code is supposed to do, but what it actually does. Why is that useful? First, it is an effective way of documenting what a system actually does, particularly if --- as with most legacy code --- there is no other documentation. And it can tell you when you have changed that existing behavior.
Feathers' style is easy to read. As you would expect there is lots of example code here, and it is folded naturally into the explanatory text. My only gripe with the book is with the examples: they are largely in Java, C++, or C. I would have liked some examples in older legacy-only languages, like COBOL.
But overall, this book is simply supurb, a tour de force of an important topic that has received little coverage before.