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.

I think most of the information is pretty straightforward for those who have modeled objects and component packages. Anyone familiar with test driven design and other extreme programming practices probably have come to most of the same conclusions that this book shows examples of.

While it is very thorough, it is not very concise.

In the end i gave it 5 stars because it's the ONLY book that i've ever seen that gives this type of information in ANY format. I applaud the author for taking such a hard topic and putting it in writing. Sometimes I have to have examples like this to show to other developers when they 'cry' about not being able to unit test.

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".

If your job is working with Legacy Code, then you need to pick up this book. If you follow his line of reasoning, you can pick up solid habits to systematically revitalize legacy code. The main emphasis of the book is applying unit testing to legacy code for in the authors opinion, legacy code is simply "code without unit tests." You may or may not agree with this statement, but the techniques he presents to find "seams" as he calls them in the code to allow you to break dependencies are vital to working with legacy code even if you choose not to apply unit testing to your projects. Some developers may attack the simplicity of the examples presented, saying they don't represent real-world examples, but if you "read" the text accompanying them you learn the techniques to tackle legacy code issues. Although I noted many publishing glitches - places where sentences to entire paragraphs are repeated from one page to another, the content is solid.

[...]

This is a must-read for software developers, I think. It's up there with Code Complete as a must-have, and I think does a better job than Refactoring by Fowler of explaining Refactoring. I started using some of the techniques in this book immediately and found that coding was higher quality and more enjoyable. It also helps to understand that the author's definition of "legacy code" is "code without tests".