Anyone could tell me the main differences between this book and Michael Feather’s “Working Effectively with Legacy Code”? Thanks
I haven’t read the Feather book, but from a quick look on Amazon, I think it’s focus is more about actually working with legacy code, whereas this book is not.
Honestly, I thought “Beyond Legacy Code” would provide practical techniques for taking a legacy code base and moving forward with it. However, having read half the book now from the beginning and then started into different chapters, it appears to be far more focused on making sure that new code doesn’t become legacy code.
Indeed, in some ways I found the book to be a re-statement of many of the current trends in modern software development, like TDD, continuous integration, pair programming etc. It frames these in the context of how good use of them will avoid the creation of legacy code, but it does not attempt, in my view, to show how to use these practices on an existing legacy codebase to bring it up to date (with the exception of Chapter 13 which does have some practical suggestions).
The author clearly has great experience on working on large, old, codebases and rescuing projects that were struggling. I would have loved to hear more examples of those successes and what practical steps were taken and the obstacles overcome. By and large, I don’t need to be educated more on modern software practices or their value and didn’t buy the book expecting quite the approach that it takes.
I hope this answers your question!
It’s true that my book is “far more focused on making sure that new code doesn’t become legacy code.”
I’ve read Michael Feather’s book, Working Effectively with Legacy Code, and it’s outstanding. If you’re a developer working with legacy code then I highly recommend Michael’s book along with Martin Fowler’s book, Refactoring: Improving the Design of Existing Code. In fact, I’ve quoted both of those books in Beyond Legacy Code to provide additional context. There are other great books on how to work with legacy code but those two are my favorites.
My book focuses on the motivation behind the practices, what they are and why they are important so developers and non-developers can get on the same page and understand the purpose of these practices and how to get the most out of using them. I often find managers don’t understand the purpose of the technical practices as deeply as they should, and even developers can misapply them and not get the benefit they should from them. In the book, I share some of my experiences applying these practices and how to avoid common pitfalls I’ve seen teams fall into. I also discuss practices that keep us from creating legacy code in the first place. I’ve taken this approach because we must understand what good code looks like before we discuss refactoring poor code into something better.
There are now several good books on working with legacy code but as far as I know there aren’t any good books that discuss the importance of technical practices so our managers and non-technical stakeholders can understand, while helping developers avoid common pitfalls of applying XP practices, which is what Beyond Legacy Code does.
I’ve read both books now and can admit, that the practices described in this book could help you to avoid the necessity to use the practises described in Michael Feathers book.
I can recommend both books. In addition, I can also recommend “Refactoring to patterns” by Joshua Kerievsky.
I think a lot of practices described in “Beyond legacy code” should be part of every education for programmers. Some parts are imho not easy to understand if you are at the beginning of your career, but if you want to work in enterprise development, these practises can be very, very helpful.
Some practises are very easy to adopt immediately. So I think a lot of readers could benefit really quickly from the book (at least if they’re not doing that practice by now).
I once heard the term “The Legacy Coder” on a Conference. This book could help getting rid of them (and sometimes a little bit of psychology ;-).