Book Review: Refactoring, 2nd Edition

Even though I had the Refactoring, First Edition, I had to have this book. Today, I review Martin Fowler's Refactoring, 2nd Edition.

When Martin Fowler released the first edition of Refactoring in 1999, refactoring was a word most developers didn't even think twice about when writing code. I know I didn't at the time.

Now, developers consider this book as one of the best programming books in the industry. To refactor code is considered to be one of the characteristics most programmers should know. It's even one of my books I recommend to developers and add to their library for reference purposes.

When I heard about Mr. Fowler "refactoring" his Refactoring book (see what I did there?), it made me wonder what else he could add to it. His first edition was already a classic in my book (ok, I'll stop with the puns).

When he was marketing his book, he mentioned the following:

• The book would be in JavaScript instead of Java.
• Reworking the Refactoring.com site to include his latest book.
• The size of the book is ALMOST the same number of pages, but is thinner.

The language of choice may throw some people off from buying the book, but I can assure you, these techniques apply to any language and contribute to the goal of solid software development.

Keep in mind, the first edition was created using examples in Java and was a best seller. I still recommend this book to C# developers. With the concepts being so similar, it doesn't matter whether you use C# or Java, everything works out in the end when writing cleaner code.

As mentioned, the book is meant for two kinds of readers: the student and teacher, or simply, beginning developers and veteran developers.

For the beginning developers, chapters 1-4 is meant to provide a history of refactoring, terminology, code smells, and testing.

For advanced developers, who purchased Refactoring, 1st Edition or who already know about the terms, testing, and code smells, the catalog in the back 2/3 of the book gives developers a quick reference of refactoring categories and sub-categories for easy code samples and knowing how to fix the code.

Let's dig into the chapters, shall we?

Chapter 1 - Refactoring, a first example

This chapter is probably the number one reason to purchase this book.

As a student or teacher, you want to know what goes on inside the brain of a seasoned developer/programmer/engineer while they are refactoring their code.

This is the chapter you need to read.

Mr. Fowler takes a sample project and walks the reader through refactoring code. It's basically the thought process of an experienced developer refactoring a project.

Think of it as "Inside the mind of how Martin Fowler refactors code."

As done in the first edition, he refers to sections in the book as to how each refactoring is done. For those writing C# code in Visual Studio, I'm sure Resharper hotkeys go through your mind as you read this chapter.

Writing this chapter is exactly what most developers look for when deciding where to start on how to refactor code. What is the process, what technique do you use, and how is it implemented without looking like spaghetti?

Speaking of implemented properly, I also wanted to bring this to every developer's attention. You'll notice in his writing he constantly "compiles, tests, and commits" after every refactoring. This is important!

• Compile to make sure everything runs right.
• Build (and run!) your tests to confirm your code you worked on passes.
• Commit your code once everything works.

Writing tests are absolutely necessary when refactoring code. If you don't have existing tests to confirm you code is "testable," write them. Based on chapter one, it seems to be a subtle nudge to create them (translation: Write them!).

I found this chapter essential in the thought process of how to refactor.

If you can read your code, I'm guessing the next person to look at it next will understand it as well.

Chapter 2 - Principles in Refactoring

If you're ever wondering what the definition of refactoring is, where it came from, and when (and why) to refactor, this chapter provides the background of refactoring, explains all of the terminology, and the reasoning for refactoring code.

One of the sections called When Should We Refactor with a number of explanations. The one explanation titled "What should I tell my manager?" is an interesting one.

In my experiences, managers are scared of the word "refactor," but are even more afraid of the word "rewrite."

Mr. Fowler explains the best thing to tell your manager is to not tell them anything at all ("don't tell!").

I am all for it provided you don't break anything and you have solid unit tests to back up your refactor. I would hate to have something new break when it wasn't supposed to.

Remember, "compile, test, commit."

Chapter 3 - Bad Smells in Code

This is another one of my favorite chapters.

Badly written code is given the term "Code Smells" and this chapter explains 99% of all code smells out there that scream "refactor me!"

For example, we've all seen the "Long Function/method" totaling 200 lines of code. Code smell! Refactor it!

Or the "Long Parameter List" of 15 parameters passed into a method. Yikes! Code smell...Time to Refactor!

Or "Duplicated Code." It's better to follow the DRY principle (Don't Repeat Yourself).

Or "Loops." Yes, Loops. Sometimes it makes sense to replace a loop with a LINQ statement or using the map, reduce, or filter functions in JavaScript (Replace Loops with Pipeline on page 231)

These code smells can be something developers come across every day. Identifying these code smells are the key to better programming which is why this chapter is critical to the book.

Review this chapter to effectively identify code smells.

Chapter 4 - Building Tests

We've all heard about testing and how it helps our refactoring in the end.

This chapter covers how to build tests to make the code work as expected by testing the code's behavior. As with Chapter 1, this chapter is also meant for developers to understand the workflow on how to build proper unit tests.

One of the comments in this section resonated with me. Mr. Fowler said, "My focus is to test the areas that I'm most worried about going wrong. That way, I get the most benefit for my testing effort." I couldn't agree more.

It's one thing to write test after test after test to make sure your code runs properly, but the test has to have meaning; to provide a valid test of your code and essentially not turn into just another number on the stack of your "code coverage" statistics. Give the unit test purpose.

Another piece of advice that resonated with me was the comment, "When you get a bug report, start by writing a unit test to expose the bug."

I've said this to a number of our developers. It just makes sense when improving your DevOps pipeline. If the bug appears again, you are made aware of it through the new unit test. If it squeaks through again, write another unit test to stop the leak, little dutch boy!

Chapter 5 - Introducing the Catalog; Chapter 6-12 - The Catalog

Finally, we have the catalog.

Throughout the book, Mr. Fowler explains the different patterns of rehow to his thought-process by referring to the refactoring in the catalog by name and page number.

In my opinion, this part of the book is meant for reference purposes when you are looking for a refactoring which makes sense in the scenario you encounter.

Each refactoring comes with the following structure:

• Sketch - A graphic to show the visual refactoring implementation.
• Original Code - The starting code a developer is given to refactor.
• Ending Code - The goal of what the code should look like after a successful refactoring.
• Motivation - An explanation as to why we would want to modify the original code? I'm sure some developers ask this all the time ("It works, why touch the code?").
• Mechanics - A step-by-step description on how to perform the refactoring.
• Example (optional) - Very simple use of the refactoring to show how it works.

The following chapters are based on the specific type of refactoring required for the situation.

• Chapter 6 - A First Set of Refactorings
• Chapter 7 - Encapsulation
• Chapter 8 - Moving Features
• Chapter 9 - Organizing Data
• Chapter 10 - Simplifying Conditional Logic
• Chapter 11 - Refactoring APIs
• Chapter 12 - Dealing with Inheritance

While I'm continuing to read through the catalog, I haven't come across a situation where I can implement every single refactoring.

I bought the book (and ebook) last month and is now considered as one of my books within reach.

Conclusion

After reading through the first 4 chapters of the book, I can say three things about the book:

• Refactoring, 2nd Edition is already considered a classic in my library.
• It's a Signature Series book. These books (as I've mentioned before) contain wisdom from industry experts who have numerous years of experience behind them. The Signature Series books prove it.
• Whether it's for student or teacher, this book is timeless. It can be used for numerous third-generation languages where patterns seem apparent.

I would highly recommend this book for web developers using C#, Java, or JavaScript.

Each refactoring in the book presents a perspective on code in two ways:

• This is what bad code looks like.
• This is what good, refactored code looks like.

Mr. Fowler, this was an exceptional book and I thoroughly enjoyed it.

For my readers, if you are interested in the book, it's sold on Amazon (affiliate link) and on InformIT (affiliate link).

What did you love about this book? Did you purchase it yet? and why not? Post your comments below and let's discuss.