Refactoring: Improving the Design of Existing Code by Martin Fowler - still relevant ?

[Tom Joe]

I know how to use some of the "refactoring" features in my IDE (Intellij IDEA). I am looking for a book to learn when and how to refactor code. I came across the book - Refactoring: Improving the Design of Existing Code by Martin Fowler (1st edition). The 1st edition was released in 1999 and it uses Java whereas the 2nd edition uses Javascript. The 2nd edition is useful only if you know Javascript. Moreover, Java 1.2 was the latest version of Java in 1998-99. So, I am not sure if this book is still useful today.

Could someone please let me know if the book is still useful and relevant today ? Please state the reasons for your answer. Are there any newer alternatives to this book which use Java ?

Thank you !

[Junilu Lacar]

I think "Refactoring" 1st Edition is still relevant, even after 20 years since it was published. The value is not so much the actual techniques themselves (there are about 70+ that are catalogued in the book) or the code smells (22 of them in the first edition, 24 of them in the second edition) but in the general approach and discipline that you will slowly incorporate in your development habits as you use the techniques and apply the concepts. Doing this will cultivate a deeper understanding of basic design principles on which the techniques are based. The refactoring techniques and code smells are just glimpses of two sides of good design principles, which to me are more or less timeless.

Let me give you an analogy to better explain what I mean. Distance, timing, focus, and centeredness are basic principles of many fighting arts. How you apply these principles can be manifested in different techniques. Each art has their own unique ways of attacking and defending but if you look closely at two different fighting styles and their techniques, you will also find many similarities. Those similarities usually line up around the principles. Someone who has studied Wing Chun kung fu for a long time can easily see similarities in other martial arts like Japanese Jiujutsu or Aikido, and vice versa, if they have a good understanding of the common principles those different techniques are based on.

When it comes to programming and software development, refactoring really boils down to making code easier to understand and change. That's it. Everything can be traced back to this basic principle, that good designs are easy to understand and change. So, just as a good martial artist studies different techniques with the aim of tying them back to principles, a good developer will study different refactoring techniques with the aim of tying it back to the principle of making code easy to understand and change. And that is something that will always be necessary.

Here are more specific design principles you should try to understand by studying refactoring:
1. Clarity/Expressive - what makes code clear/unclear and expressive/convoluted
2. Loose coupling - what makes code loosely / tightly coupled
3. Cohesiveness / Coherence - what makes code more or less cohesive/coherent
4. Simplicity - what characteristics of software contribute to simplicity/complexity

[Junilu Lacar]

With regard to the languages used in the book examples, I think that you have to keep the principles in mind instead of focusing on the language elements and mechanics themselves. There's a bit of a Catch-22 here though. To understand how good design principles are applied through the techniques, you need to be able to see beyond the language itself. But in order to see beyond the language itself, you first need to understand the language!

The principles and techniques in the first edition can just as easily be applied to languages besides Java, like C# for example. I think that the same goes for the 2nd edition that uses JavaScript for its examples.

[Tom Joe]

Junilu Lacar wrote:With regard to the languages used in the book examples, I think that you have to keep the principles in mind instead of focusing on the language elements and mechanics themselves. There's a bit of a Catch-22 here though. To understand how good design principles are applied through the techniques, you need to be able to see beyond the language itself. But in order to see beyond the language itself, you first need to understand the language!

The principles and techniques in the first edition can just as easily be applied to languages besides Java, like C# for example. I think that the same goes for the 2nd edition that uses JavaScript for its examples.

Thanks for your replies ! Much appreciated. I am going to use the 1st edition because it uses Java.

PS - It would have been helpful if the authors of 2nd edition would have listed the JS topics needed to understand the book and maybe even pointed us to resources to learn them. That way we could figure out how much time it would take to learn enough JS for the refactoring book and it if the effort is worth it.

[Junilu Lacar]

Tom Joe wrote:PS - It would have been helpful if the authors of 2nd edition would have listed the JS topics needed to understand the book and maybe even pointed us to resources to learn them. That way we could figure out how much time it would take to learn enough JS for the refactoring book and it if the effort is worth it.

Those are arguably out of scope for the book. I don't think there's a whole lot of mysterious code in the second edition (I have both). I don't often work with JavaScript but so far I haven't seen any examples in the second edition that were real headscratchers or things I'd have to spend a lot of extra time looking up further information on.

Here's another tip in studying refactoring: understand the code smell that provides the motivation to apply a particular refactoring technique. This is very important, the why of refactoring. If you don't understand the "why" behind the technique, you could very easily end up mis-applying a technique and lose out on the benefit of refactoring. Or worse yet, a refactoring technique misapplied could lead to code that's more complex and more difficult to understand and change. So again, always understand the code smell that you're trying to address and why applying a refactoring mitigates or eliminates that smell.

One last tip: I like to start teaching refactoring by having people look for violations of Kent Beck's 4 Rules of Simple Design.  Many of the more specific code smells stem from violations of one or more of these four basic design rules.