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


Published on

Published in: Technology

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


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