WhatsApp 9892124323 ✓Call Girls In Kalyan ( Mumbai ) secure service
Principlesinrefactoring 090906230021-phpapp01
1.
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.
5.
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!
12.
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.