Your SlideShare is downloading. ×
Principles in Refactoring
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Principles in Refactoring

2,274
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,274
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
82
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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