Working Effectively with Legacy Code,   ISBN:9780131177055

Customer Rating: 

It should be no secret that the majority of commercial software development effort consists of dealing with other people's poorly constructed code, yet this book is one of only a handful of sources that offer any practical advice for such undertakings, and the closest thing to a comprehensive reference on the subject so far as I know.

Here you'll find dozens of useful techniques organized according to the kind of problem that they address, each explained concisely with concrete examples. Lots of them are things that I've had success with in the past, and of the ones I haven't tried yet, there's nothing in my 19 years of industry experience that leads me to doubt that they work.

A word of caution, though: It understates both the difficulty and the importance of having everyone who works on the same code to buy into the ideas it puts forth. Negligent programmers will resist change because they tend to benefit from "adverse selection" (look it up on Wikipedia), and you really don't want to be the only one worrying about code coverage and maintainability while everyone else creates messes for you to clean up. Appealing to engineering wisdom and common interest is not always so easy as it sounds.

But on the whole, this is fine advice, and every programmer should own a copy. Not only will it help you to better the quality of your life by improving the state of your most troublesome projects, but also it will teach you to minimize the problems that you create in the first place, as well as how to fix those problems before they become too costly.

Customer Rating: 

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.

Customer Rating: 

This was one of those famous, timeless books (like Code Complete) that I had heard many people talk about, and I finally read it. To be honest it was in my Amazon "Wish List" for several months before I ordered it, but it lived up to the hype.

Remember when you first started writing software? Like most people, for me it was a very exciting time and I truly enjoyed learning and trying to push the boundaries of programming. It is a very primal passion that engulfed me, and it is the reason many of us got into this industry. Where did that go? Do you still feel that today? If so, you are one of the lucky ones. In this book, Michael explains how large code bases (that don't have tests around them) can sometimes suck that enjoyment out of our day-to-day tasks, because we slowly develop a fear making changes to this monolithic application because we are worried about what we might break or what expected side-effects fixing a bug or adding a new feature might have. Although we might not typically acknowledge this fear, it is present whether we admit it or not.

Sometimes we romanticize the idea of working on "Greenfield" projects, because if we were just able to start from scratch ... this would be much easier and a lot more fun. I have slowly become convinced that isn't the case. There is tedious and unexpected ripples in new projects just like existing projects. This book is dedicated to given practical techniques to remove that fear, and get to a place where you can actually enjoy working in your code base. It is possible, and Michael has the experience and expertise to help you bring your legacy systems under control.

I often am weary that books like this that are on "hot" topics like test-driven-development are fluff, and aren't very relevant to my day-to-day real-world code. Not true ... at least not on this book. I would highly recommend this to book to anyone. It is worth the money, time, and effort to read it cover-to-cover. This is probably in my top 5 for technology books in terms of real-world value they provide.

To read the full review or find more reviews for technical books, visit [...]

Customer Rating: 

I have read many books by the most respected names in software development. This book is probably the best software development book that I have ever read. The advice is very practical. Anyone developing software should consider this a must-read.

The recipes will help you get your system under test. Once you have good test coverage, you will be able to modify the structure of your code without worrying that you are breaking something. You will also find yourself more productive writing new code if you can follow the advice and principles laid out in this book.

You will not regret purchasing this book.

Customer Rating: 

This is a must-read for software engineers. It clarifies some powerful techniques for bridging the gap between legacy (test-less and/or untestable) code and fresh, testable code. And BTW legacy doesn't necessarily mean somebody else's code, it could be code you wrote last week.