2. Defining Refactoring
The word Refactoring has two definitions
depending on context.
Refactoring (noun): a change made to the
internal structure of software to make it easier to
understand and cheaper to modify without
changing its observable behavior.
Refactor (verb): to restructure software by
applying a series of refactorings without
changing its observable behavior.

3. Defining Refactoring
The purpose of refactoring is to make the software
easier to understand and modify.
It only alters the internal structure.
A good contrast is performance optimization.
Refactoring does not change the observable
behavior of the software.

4. The Two Hats
Two distinct activities: adding function and
refactoring.
When you add function, you shouldn't be changing
existing code; you are just adding new capabilities.
When you refactor, you make a point of not adding
function; you only restructure the code.

6. Refactoring Improves the Design of
Software
Without refactoring, the design of the program will
decay.
Poorly designed code usually takes more code to do
the same things.

7. Refactoring Makes Software Easier to
Understand
Programming is in many ways a conversation with a
computer.
There is another user of your source code.
“I use refactoring to help me understand unfamiliar
code.
I actually change the code to better reflect my
understanding.”

8. Refactoring Helps You Find Bugs
Help in understanding the code also helps me spot
bugs.
"I'm not a great programmer; I'm just a good
programmer with great habits."

9. Refactoring Helps You Program Faster
Refactoring helps you develop software more
rapidly, because it stops the design of the system
from decaying.

10. When Should You Refactor?
Refactor When You Add Function
Refactor When You Need to Fix a Bug
Refactor As You Do a Code Review

11. What Do I Tell My Manager?
If the manager is technically savvy, introducing
the subject may not be that hard.
If the manager is genuinely quality oriented, then
the thing to stress is the quality aspects.
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!

13. Databases
Most business applications are tightly coupled to the
database schema that supports them.
The database is difficult to change.
Another reason is data migration.
With nonobject databases, place a separate layer of
software between your object model and your
database model.
Object databases both help and hinder.

14. Changing Interfaces
There is no problem changing a method name if you
have access to all the code that calls that method.
There is a problem only if the interface is being used
by code that you cannot find and change.
Don't publish interfaces prematurely. Modify your
code ownership policies to smooth refactoring.

15. Design Changes That Are Difficult to
Refactor
How difficult would it be to refactor from one design
into another?
Pick the simplest design if it seems easy.
Otherwise put more effort into the design.

16. Refactoring and Design
Refactoring can be an alternative to upfront design.
In refactoring, you still do upfront design, but now
you don't try to find the solution. Instead all you want
is a reasonable solution. You know that as you build
the solution, as you understand more about the
problem
An important result of this change in emphasis is a
greater movement toward simplicity of design.

17. Refactoring and Performance
A common concern with refactoring is the effect it
has on the performance of a program.
Three general approaches to writing fast software:
time/footprint budget for resources
constant attention approach
performance improvement

18. Where Did Refactoring Come
From?
Two of the first people to recognize the importance
of refactoring were Ward Cunningham and Kent
Beck, who worked with Smalltalk from the 1980s
onward.