Refactoring Improving the Design of Existing Code

Martin Fowler, Kent Beck

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. 

It is a disciplined way to clean up 

code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written. ​

No silver bullet

• Each refactoring method goes in both way (extract method <-> inline method

• It's up to developer to choose what makes code cleaner

• Tip

  When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.

First step for refactoring is good test suite

The Two Hats

Refactor with small changes

In almost all cases, I'm opposed to setting aside time for refactoring. In my view refactoring is not an activity you set aside time to do. Refactoring is something you do all the time in little bursts. You don't decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing.

The Rule of Three

Here's a guideline Don Roberts gave me: The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.

When to refactor

• Refactor When You Need to Fix a Bug

• Refactor As You Do a Code Review

• Refactor When You Add Function

What Do I Tell My Manager?

"Of course, many people say they are driven by quality but are more driven by schedule. In these cases I give my more controversial advice: Don't tell!"

Subversive? I don't think so. Software developers are professionals. Our job is to build effective software as rapidly as we can. My experience is that refactoring is a big aid to building software quickly. If I need to add a new function and the design does not suit the change, I find it's quicker to refactor first and then add the function. If I need to fix a bug, I need to understand how the software works—and I find refactoring is the fastest way to do this. A schedule-driven manager

wants me to do things the fastest way I can; how I do it is my business. The fastest way is to refactor; therefore I refactor.