When Should You Refactor

Facebook 718 Twitter 1076 Google+

(/) / Refactoring (/refactoring) / Introduction to Refactoring

(/refactoring/introduction-to-refactoring)

When I talk about refactoring, I'm often asked about how it should

be scheduled. Should we allocate two weeks every couple of

months to refactoring?

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 ThreeHere'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.

Three strikes and you refactor.

Refactor When You Add FunctionThe most common time to refactor is when I want to add a new

feature to some software. Often the first reason to refactor here is

to help me understand some code I need to modify. This code

may have been written by someone else, or I may have written it.

Whenever I have to think to understand what the code is doing, I

ask myself if I can refactor the code to make that understanding

more immediately apparent. Then I refactor it. This is partly for the

next time I pass by here, but mostly it's because I can understand

more things if I clarify the code as I'm going along.

The other driver of refactoring here is a design that does not help

me add a feature easily. I look at the design and say to myself, "If

only I'd designed the code this way, adding this feature would be

easy." In this case I don't fret over my past misdeeds—I fix them

by refactoring. I do this partly to make future enhancements easy,

but mostly I do it because I've found it's the fastest way.

Refactoring is a quick and smooth process. Once I've refactored,

adding the feature can go much more quickly and smoothly.

Refactor When You Need to Fix aBug

Refactoring (/refactoring

Introduction to


/introduction-

to-refactoring)

Introduction to


/introduction-

to-refactoring)

Defining Refactoring

(/refactoring/defining-

refactoring)

Why Should You

Refactor? (/refactoring

/why-should-

you-refactor)

Refactoring Helps You

Find Bugs (/refactoring

/refactoring-helps-

you-find-bugs)

When Should You

Refactor? (/refactoring

/when-should-

you-refactor)

What Do I Tell My

Manager? (/refactoring

/what-do-i-tell-

my-manager)

Problems with


/problems-

with-refactoring)

Refactoring and Design

(/refactoring/refactoring-

and-design)

Refactoring and

Performance

(/refactoring/refactoring-

and-performance)

Where Did Refactoring

Come From?

(/refactoring/where-

did-refactoring-

come-from)

Code smells (/refactoring

/bad-smells-in-code)

When Should You Refactor? https://sourcemaking.com/refactoring/when-should-you-refactor

1 of 6 10/12/2015 11:03 AM

In fixing bugs much of the use of refactoring comes from making

code more understandable. As I look at the code trying to

understand it, I refactor to help improve my understanding. Often I

find that this active process of working with the code helps in

finding the bug. One way to look at it is that if you do get a bug

report, it's a sign you need refactoring, because the code was not

clear enough for you to see there was a bug.

Refactor As You Do a Code ReviewSome organizations do regular code reviews; those that don't

would do better if they did. Code reviews help spread knowledge

through a development team. Reviews help more experienced

developers pass knowledge to less experienced people. They

help more people understand more aspects of a large software

system. They are also very important in writing clear code. My

code may look clear to me but not to my team. That's

inevitable—it's very hard for people to put themselves in the

shoes of someone unfamiliar with the things they are working on.

Reviews also give the opportunity for more people to suggest

useful ideas. I can only think of so many good ideas in a week.

Having other people contribute makes my life easier, so I always

look for many reviews.

I've found that refactoring helps me review someone else's code.

Before I started using refactoring, I could read the code,

understand some degree of it, and make suggestions. Now when I

come up with ideas, I consider whether they can be easily

implemented then and there with refactoring. If so, I refactor.

When I do it a few times, I can see more clearly what the code

looks like with the suggestions in place. I don't have to imagine

what it would be like, I can see what it is like. As a result, I can

come up with a second level of ideas that I would never have

realized had I not refactored.

Refactoring also helps the code review have more concrete

results. Not only are there suggestions, but also many

suggestions are implemented there and then. You end up with

much more of a sense of accomplishment from the exercise.

To make this process work, you have to have small review groups.

My experience suggests having one reviewer and the original

author work on the code together. The reviewer suggests

changes, and they both decide whether the changes can be easily

refactored in. If so, they make the changes.

With larger design reviews it is often better to obtain several

opinions in a larger group. Showing code often is not the best

device for this. I prefer UML diagrams and walking through

scenarios with CRC cards. So I do design reviews with groups

and code reviews with individual reviewers.

This idea of active code review is taken to its limit with the

Extreme Programming [Beck, XP] practice of Pair Programming.

With this technique all serious development is done with two

developers at one machine. In effect it's a continuous code review

folded into the development process, and the refactoring that

Code smells

(/refactoring/bad-smells-

in-code)

Duplicated Code

(/refactoring

/duplicated-code)

Long Method

(/refactoring/long-

method)

Large Class (/refactoring

/large-class)

Long Parameter List

(/refactoring/long-

parameter-list)

Divergent Change

(/refactoring/divergent-

change)

Shotgun Surgery

(/refactoring/shotgun-

surgery)

Feature Envy

(/refactoring

/feature-envy)

Data Clumps

(/refactoring/data-

clumps)

Primitive Obsession

(/refactoring/primitive-

obsession)

Switch Statements

(/refactoring/switch-

statements)

Parallel Inheritance

Hierarchies (/refactoring

/parallel-inheritance-

hierarchies)

Lazy Class (/refactoring

/lazy-class)

Speculative Generality

(/refactoring/speculative-

generality)

Temporary Field

(/refactoring/temporary-

field)

Message Chains

(/refactoring/message-

chains)

Middle Man (/refactoring

/middle-man)

Inappropriate Intimacy

(/refactoring

/inappropriate-intimacy)


2 of 6 10/12/2015 11:03 AM

takes place is folded in as well.

Why Refactoring WorksKent Beck

Programs have two kinds of value: what they can do for you today and

what they can do for you tomorrow. Most times when we are programming,

we are focused on what we want the program to do today. Whether we are

fixing a bug or adding a feature, we are making today's program more

valuable by making it more capable.

You can't program long without realizing that what the system does today is

only a part of the story. If you can get today's work done today, but you do it

in such a way that you can't possibly get tomorrow's work done tomorrow,

then you lose. Notice, though, that you know what you need to do today,

but you're not quite sure about tomorrow. Maybe you'll do this, maybe that,

maybe something you haven't imagined yet.

I know enough to do today's work. I don't know enough to do tomorrow's.

But if I only work for today, I won't be able to work tomorrow at all.

Refactoring is one way out of the bind. When you find that yesterday's

decision doesn't make sense today, you change the decision. Now you can

do today's work. Tomorrow, some of your understanding as of today will

seem naive, so you'll change that, too.

What is it that makes programs hard to work with? Four things I can think

of as I am typing this are as follows:

Programs that are hard to read are hard to modify.

Programs that have duplicated logic are hard to modify.

Programs that require additional behavior that requires you to change

running code are hard to modify.

Programs with complex conditional logic are hard to modify.

So, we want programs that are easy to read, that have all logic specified in

one and only one place, that do not allow changes to endanger existing

behavior, and that allow conditional logic to be expressed as simply as

possible.

Refactoring is the process of taking a running program and adding to its

value, not by changing its behavior but by giving it more of these qualities

that enable us to continue developing at speed.

Composing Methods

(/refactoring/composing-

methods)

Moving Features

Between Objects

(/refactoring/moving-

features-between-

objects)

Organizing Data

(/refactoring

/organizing-data)

Organizing Data

(/refactoring

/organizing-data)

Self Encapsulate Field

(/refactoring/self-

encapsulate-field)

Replace Data Value with

Object (/refactoring

/replace-data-value-

with-object)

Change Value to

Reference (/refactoring

/change-value-

to-reference)

Change Reference to

Value (/refactoring

/change-reference-

to-value)

Replace Array with


/replace-array-

with-object)

Duplicate Observed

Data (/refactoring

/duplicate-

observed-data)

Change Unidirectional

Association to

Bidirectional

(/refactoring/change-

unidirectional-

association-

to-bidirectional)

Change Bidirectional

Association to

Unidirectional

(/refactoring/change-

bidirectional-association-

to-unidirectional)

Replace Magic Number

Reading is boringAren't you bored of reading so

much? Try out our new interactive

learning course on refactoring. It's

much more fun.

Learn more (/refactoring-course)

(/refactoring-course)


3 of 6 10/12/2015 11:03 AM

RefactoringHelps YouFind Bugs(/refactoring/refactoring-

helps-you-find-bugs)

Introductionto Refactoring(/refactoring/introduction-to-refactoring)

What Do I TellMy Manager?(/refactoring/what-do-i-tell-my-manager)

Simplifying Conditional

Expressions (/refactoring

/simplifying-conditional-

expressions)

Making Method Calls

Simpler (/refactoring

/making-method-calls-

simpler)

Making Method Calls

Simpler (/refactoring

/making-method-calls-

simpler)

Rename Method

(/refactoring/rename-

method)

Add Parameter

(/refactoring

/add-parameter)

Remove Parameter

(/refactoring/remove-

parameter)

Separate Query from

Modifier (/refactoring

/separate-query-

from-modifier)

Parameterize Method

(/refactoring

/parameterize-method)

Replace Parameter with

Explicit Methods

(/refactoring/replace-

parameter-with-explicit-

methods)

Preserve Whole Object

(/refactoring/preserve-

whole-object)

Replace Parameter with

Method (/refactoring

/replace-parameter-

with-method)

Introduce Parameter


/introduce-parameter-

object)

Remove Setting Method

(/refactoring/remove-

setting-method)

Hide Method

(/refactoring/hide-

method)

Replace Constructor


4 of 6 10/12/2015 11:03 AM

Dealing with

Generalization

(/refactoring/dealing-

with-generalization)

Big Refactorings

(/refactoring

/big-refactorings)

Refactoring Course (/refactoring-course)new

SourceMaking(/)

Design Patterns (/design_patterns)

AntiPatterns (/antipatterns)

My account (/user)


5 of 6 10/12/2015 11:03 AM

Refactoring (/refactoring)

UML (/uml)

Forum

(https://sourcemaking.userecho.com/)

Contact us

(https://sourcemaking.userecho.com

/?show_feedback_form_private=true)

About us (/about-us)


6 of 6 10/12/2015 11:03 AM

Documents

When Should You Refactor