Five Refactor Books

Introduction

This list has books that have been around for 15-20 years and will likely apply for 15-20 more. They came out during the “golden” period of 1995-2005 when Design Patterns, Refactoring, and eXtreme Programming broke through and started becoming well-known. Future lists will cover more recent books on developer testing, object-oriented design, and tech-specific books (e.g., Java, Spring framework, etc.).

How to Read

Instead of just listing the books, I provide a recommendation on how I’d read the book, since some of them, like the 883-page xUnit Test Patterns book, are quite large (and heavy if you have the physical book), and you don’t need to read every page. Even if they’re not that long, not all of these books are meant to be read cover-to-cover and serve as cookbook-like references. These books also have quite a bit of code and I tend to skip over most of that on my first read-through. Unlike most people it seems, I actually enjoy reading the Preface and Introduction chapters of books and since they often provide their own “how to read this book” advice, it’s worth taking the extra time to read.

If you can, read these books as part of a Study Group. I was lucky to be part of a group (the Silicon Valley Patterns Group) that met weekly to discuss these books (and many more), chapter by chapter, and followed the patterns described here. We were also lucky enough to get access to the in-progress books (such as WELC and DDD) and provide feedback to the authors.

Disclaimer

This list has affiliate links where I might make a few cents on your purchase, but in addition to the typical Amazon links, I’ve included links (IndieBound) that would help support local and independent bookstores, without which the world would be a poorer place. I look forward to the day when I can leisurely and casually browse my local bookstores again. If the indie bookstores in your area aren’t yet open (e.g., for curb-side pickup or drop-off), you can buy from indie bookstores online by following the link to BookShop.

The Forever List

And now, on to the list! These are my Top 5 “forever” (aka “classic”) books that I strongly recommend folks buy and have on their shelf. They are not in any particular order, so I’m not numbering them. Except for eXtreme Programming eXplained, they’re not books that are meant to be read linearly all the way through, but contain a catalog of recipes to be slowly learned over time.

“Working Effectively with Legacy Code” by Michael Feathers

This is the book that most people reference when discussing dealing with legacy code, which, let’s be honest, is probably all of us. Usually shortened to WELC.

• Read Chapters 1-4
• Skip Chapter 5 (Tools)
• Read Chapter 6 (I Don’t Have Much Time and I Have to Change It)
• Skim the rest of the book, that way you’re aware of techniques to use when you run into those situations. Or maybe you’re already in those situations? If so, read on!

“xUnit Test Patterns” by Gerard Meszaros

This book’s subtitle is “Refactoring Test Code”, but I think it’s much more than that, as it got me to really think about how I write and structure automated tests.

• Read Introduction through Chapter 6. No really, read the Introduction.
• Skip Chapter 7 if you know JUnit/xUnit etc.
• Skip Chapters 8, 9 on Fixture Management – I don’t think it’s as important as other chapters.
• Read Chapter 10 for how to verify (assert) – you might be surprised what you learn from this chapter.
• Read Chapter 11 at least twice(!) about “Test Doubles”
  • Forget everything you knew about mocks and learn this terminology.
  • Eventually this will become second-nature, but if you overuse mocks in your current codebases, learning the different kinds of Test Doubles will help you wean off of them.
• Skip Chapters 12-14, unless you’re really not sure how to organize your tests. Not that it’s not important, it’s more that this isn’t the main problem that I see in teams that I coach and train.
• Skim the rest of the Chapters for Test Code Smells (Chapter 15ff) and Test Strategy Patterns (Chapter 18ff).

“Refactoring: Improving the Design of Existing Code” by Martin Fowler

There are two editions of this book: the First Edition, from 1999, uses Java, whereas the Second Edition came out in 2018 and switched to JavaScript for the code examples (as well as being tailored towards JavaScript idioms, such as using function instead of method). There are obviously more significant changes than just the code, as described by Martin here.

So which edition to buy? If you’re not a Java developer, then the Second Edition is what you want. However, if you are a Java developer, then maybe both? The First Edition is available used for around US$15-20 used, and the Second Edition is about US$30, so I don’t think that’s too much to spend on one of the most valuable books you can get. The First Edition is nice to have available to see the refactorings in a more familiar language, and the Second Edition has improved and updated the “code smells” and principles text.

• Read Chapters 1, 2
• Skim Chapter 3 (identifies code smells)
• Can skip Chapter 4 (Test)
• Skim through list of Refactorings (Chapter 6 through to the end) – this is the refactoring “catalog”

“Domain-Driven Design” by Eric Evans

I use the patterns and the principles from this book all the time. If you’ve ever heard me speak in person or on stream, you’ll hear me use terms such as “ubiquitous language” and “context boundary” and “repository pattern” quite a bit. This is not the easiest book to understand, not because it’s poorly written, but because there’s a lot packed into it, and it’s written in a certain Pattern Language style that can take a bit of getting used to. The main point that you should take away is thinking about your applications Domain First (what should the system be doing) instead of Data[base] First (what data are we keeping track of). The more you try to use these concepts and patterns, the more you’ll start to see ways of applying them – it’s a virtuous cycle.

• Read all the way through
• On your second read-through, start with Part IV “Strategic Design” and work your way, Part by Part towards the beginning of the book.

5. “eXtreme Programming Explained” by Kent Beck

This book (also known as XP Explained) had such a huge impact on the way I, and soon enough the teams I worked with, developed software. The idea of pair programming was mind-blowing for me, and the emphasis on developer testing, something I was doing anyway, was reassuring. The flattening of the “Cost of Change” curve was also surprising as it went against what I had learned about project management of software development projects: earlier is better, later is badder. That assumption is wrong and is the cause of premature flexibility (You Ain’t Gonna Need It, aka YAGNI) that makes software less flexible rather than more.

Note: The links are for the 2nd Edition, which is almost a full rewrite of the 1st, but retains the overall thrust of XP:

XP is a style of software development focusing on excellent applica-tion of programming techniques, clear communication, and teamworkwhich allows us to accomplish things we previously could not evenimagine.

• Read the whole thing
• Discuss with your colleagues
• Read it again
• Repeat on a regular basis