Working Effectively with Legacy Code

Short and to the point. Filled with great techniques for handling legacy monsters. Much more practical than Martin Fowler's Refactoring book.

This is the canonical book for working with legacy code (and you can even learn some if you're not working with legacy code). I use the things I learned from it daily!

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. <br /> <br />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. <br /> <br />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. <br /> <br />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. <br /> <br />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. <br />

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. <br /> <br />While it is very thorough, it is not very concise. <br /> <br />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.