When Should You Refactor?

1 of 6

https://sourcemaking.com/refactoring/when-should-you-refactor
Facebook 718

Twitter 1076

Google+

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

(/refactoring/introduction-to-refactoring)

Refactoring (/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.

Introduction to
Refactoring (/refactoring
/introductionto-refactoring)
Introduction to
Refactoring (/refactoring
/introductionto-refactoring)
Defining Refactoring
(/refactoring/definingrefactoring)

The Rule of Three

Why Should You

Refactor? (/refactoring
/why-shouldyou-refactor)

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.

Refactoring Helps You

Find Bugs (/refactoring
/refactoring-helpsyou-find-bugs)

Three strikes and you refactor.

Refactor When You Add Function

The 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 misdeedsI 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 a

Bug

When Should You

Refactor? (/refactoring
/when-shouldyou-refactor)
What Do I Tell My
Manager? (/refactoring
/what-do-i-tellmy-manager)
Problems with
Refactoring (/refactoring
/problemswith-refactoring)
Refactoring and Design
(/refactoring/refactoringand-design)
Refactoring and
Performance
(/refactoring/refactoringand-performance)
Where Did Refactoring
Come From?
(/refactoring/wheredid-refactoringcome-from)

Code smells (/refactoring

/bad-smells-in-code)

10/12/2015 11:03 AM

When Should You Refactor?

2 of 6

https://sourcemaking.com/refactoring/when-should-you-refactor

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 Review

Some 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
inevitableit'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.

Code smells
(/refactoring/bad-smellsin-code)
Duplicated Code
(/refactoring
/duplicated-code)
Long Method
(/refactoring/longmethod)
Large Class (/refactoring
/large-class)
Long Parameter List
(/refactoring/longparameter-list)
Divergent Change
(/refactoring/divergentchange)
Shotgun Surgery
(/refactoring/shotgunsurgery)
Feature Envy
(/refactoring
/feature-envy)
Data Clumps
(/refactoring/dataclumps)
Primitive Obsession
(/refactoring/primitiveobsession)
Switch Statements
(/refactoring/switchstatements)

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.

Parallel Inheritance
Hierarchies (/refactoring
/parallel-inheritancehierarchies)

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.

Lazy Class (/refactoring

/lazy-class)

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

Speculative Generality
(/refactoring/speculativegenerality)
Temporary Field
(/refactoring/temporaryfield)
Message Chains
(/refactoring/messagechains)
Middle Man (/refactoring
/middle-man)
Inappropriate Intimacy
(/refactoring
/inappropriate-intimacy)

10/12/2015 11:03 AM

When Should You Refactor?

3 of 6

https://sourcemaking.com/refactoring/when-should-you-refactor

takes place is folded in as well.

Composing Methods
(/refactoring/composingmethods)

Why Refactoring Works

Kent 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.

Moving Features
Between Objects
(/refactoring/movingfeatures-betweenobjects)
Organizing Data
(/refactoring
/organizing-data)
Organizing Data
(/refactoring
/organizing-data)
Self Encapsulate Field
(/refactoring/selfencapsulate-field)
Replace Data Value with
Object (/refactoring
/replace-data-valuewith-object)
Change Value to
Reference (/refactoring
/change-valueto-reference)
Change Reference to
Value (/refactoring
/change-referenceto-value)
Replace Array with
Object (/refactoring
/replace-arraywith-object)
Duplicate Observed
Data (/refactoring
/duplicateobserved-data)
Change Unidirectional
Association to
Bidirectional
(/refactoring/changeunidirectionalassociationto-bidirectional)

Reading is boring
Aren't you bored of reading so
much? Try out our new interactive
learning course on refactoring. It's
much more fun.
(/refactoring-course)

Learn more (/refactoring-course)

Change Bidirectional
Association to
Unidirectional
(/refactoring/changebidirectional-associationto-unidirectional)
Replace Magic Number

10/12/2015 11:03 AM

When Should You Refactor?

4 of 6

Refactoring
Helps You
Find Bugs
(/refactoring
/refactoringhelpsyou-find-bugs)

https://sourcemaking.com/refactoring/when-should-you-refactor

Introduction
to Refactoring
(/refactoring
/introductionto-refactoring)

What Do I Tell
My Manager?
(/refactoring
/what-do-i-tellmy-manager)

Simplifying Conditional
Expressions (/refactoring
/simplifying-conditionalexpressions)
Making Method Calls
Simpler (/refactoring
/making-method-callssimpler)
Making Method Calls
Simpler (/refactoring
/making-method-callssimpler)
Rename Method
(/refactoring/renamemethod)
Add Parameter
(/refactoring
/add-parameter)
Remove Parameter
(/refactoring/removeparameter)
Separate Query from
Modifier (/refactoring
/separate-queryfrom-modifier)
Parameterize Method
(/refactoring
/parameterize-method)
Replace Parameter with
Explicit Methods
(/refactoring/replaceparameter-with-explicitmethods)
Preserve Whole Object
(/refactoring/preservewhole-object)
Replace Parameter with
Method (/refactoring
/replace-parameterwith-method)
Introduce Parameter
Object (/refactoring
/introduce-parameterobject)
Remove Setting Method
(/refactoring/removesetting-method)
Hide Method
(/refactoring/hidemethod)
Replace Constructor

10/12/2015 11:03 AM

When Should You Refactor?

5 of 6

https://sourcemaking.com/refactoring/when-should-you-refactor

Dealing with
Generalization
(/refactoring/dealingwith-generalization)
Big Refactorings
(/refactoring
/big-refactorings)

Refactoring Course

new

(/refactoring-course)

SourceMaking Design Patterns (/design_patterns)

AntiPatterns (/antipatterns)
(/)

My account (/user)

10/12/2015 11:03 AM

When Should You Refactor?

6 of 6

Refactoring (/refactoring)
UML (/uml)

https://sourcemaking.com/refactoring/when-should-you-refactor

Forum
(https://sourcemaking.userecho.com/)
Contact us
(https://sourcemaking.userecho.com
/?show_feedback_form_private=true)
About us (/about-us)

10/12/2015 11:03 AM