Review: Fowler's Refactoring book

We started a book club at work at the end of 2020 and the first book we went over was the extremely famous Refactoring: Improving the Design of Existing Code by Martin Fowler.

There are many, many, reviews about the book out there. First edition was published in 2000 with a second one in 2018 (the one I read) and it has been touted a must read almost since publication.

The book itself is very big, but that’s mostly the reference section with all the different techniques and applications detailed, as the interesting substance is in the first few chapters discussing and showing why you may want to do refactoring and when. I did not even look into the reference section, other than when mentioned in the first chapters.

The mindset chapters felt a bit obvious for modern practice and validated what I had experienced on my own with many hobby projects, adding very good explanations to what my intuition had detected, and a few extra quirks. It was still very helpful as someone else has already done the hard work of detailing and explaining your belief, so you don’t have to. It’s quite a light read with comfortable prose.

One of the criticisms/praises (depending on who you ask) you can often find is that the original book had all code examples in Java and the new one has the examples with Javascript. As someone who doesn’t know Javascript nor is especially interested in learning it, I can affirm it does not matter. The examples are thought to make the language a trivial matter and can be read perfectly as any other C-like syntax.

The book is beneficial to anyone that works with code over long periods of time and also points to some other practices that would later be explored in their own books, like Test Driven Development and continuous testing cycles. As someone who was at least in the periphery of the industry since 2003 (I didn’t get a job in tech until 2013 but I’d been reading and interacting with different communities for a long time before then) there are many details and references that bring me back to then.

Is it essential? No, you can spend 15 years (or less, YMMV) with ongoing coding projects and you’ll mostly get there. You can read most modern discussions and you’ll be over half the way there already. But it never hurts to get another explanation on the same thing, and the writing felt very compelling to me.

The part that has been very valuable to me has been to practice the techniques referenced as part of my ongoing refactors. It helps make some of the extra things really click in your mind, and feels quite more effective when you are dealing with complex and brittle code. I have not made a conscious practice of it (I don’t write that much code, even less refactor it, lately) but it has adjusted my mindset when splitting commits and doing exploratory refactoring in a helpful way. I dearly recommend you to practice the techniques for yourself and see if they help you.

If you want to browse the techniques, there is a Catalog online (a bit cryptic to me) at: https://refactoring.com/catalog The recommended edition of the book is in web form, as the Reference section is expanded and will be enhanced over time. If you decide to purchase it, my recommendation is that you start at https://refactoring.com


Have a comment on this article? Start a discussion in my public inbox by sending an email to ~miguelbernadi/public-inbox@lists.sr.ht [mailing list etiquette] , or see existing discussions.