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

No notes for slide

Principles in Refactoring

  1. 2. Defining Refactoring <ul><li>The word Refactoring has two definitions depending on context. </li></ul><ul><li>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. </li></ul><ul><li>Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior. </li></ul>
  2. 3. Defining Refactoring <ul><li>The purpose of refactoring is to make the software easier to understand and modify. </li></ul><ul><li>It only alters the internal structure. </li></ul><ul><li>A good contrast is performance optimization. </li></ul><ul><li>Refactoring does not change the observable behavior of the software. </li></ul>
  3. 4. The Two Hats <ul><li>Two distinct activities: adding function and refactoring. </li></ul><ul><li>When you add function, you shouldn't be changing existing code; you are just adding new capabilities. </li></ul><ul><li>When you refactor, you make a point of not adding function; you only restructure the code. </li></ul>
  4. 6. Refactoring Improves the Design of Software <ul><li>Without refactoring, the design of the program will decay. </li></ul><ul><li>Poorly designed code usually takes more code to do the same things. </li></ul>
  5. 7. Refactoring Makes Software Easier to Understand <ul><li>Programming is in many ways a conversation with a computer. </li></ul><ul><li>There is another user of your source code. </li></ul><ul><li>“ I use refactoring to help me understand unfamiliar code. </li></ul><ul><li>I actually change the code to better reflect my understanding.” </li></ul>
  6. 8. Refactoring Helps You Find Bugs <ul><li>Help in understanding the code also helps me spot bugs. </li></ul><ul><li>&quot;I'm not a great programmer; I'm just a good programmer with great habits.&quot; </li></ul>
  7. 9. Refactoring Helps You Program Faster <ul><li>Refactoring helps you develop software more rapidly, because it stops the design of the system from decaying. </li></ul>
  8. 10. When Should You Refactor? <ul><li>Refactor When You Add Function </li></ul><ul><li>Refactor When You Need to Fix a Bug </li></ul><ul><li>Refactor As You Do a Code Review </li></ul>
  9. 11. What Do I Tell My Manager? <ul><li>If the manager is technically savvy, introducing the subject may not be that hard. </li></ul><ul><li>If the manager is genuinely quality oriented, then the thing to stress is the quality aspects. </li></ul><ul><li>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! </li></ul>
  10. 13. Databases <ul><li>Most business applications are tightly coupled to the database schema that supports them. </li></ul><ul><ul><li>The database is difficult to change. </li></ul></ul><ul><ul><li>Another reason is data migration. </li></ul></ul><ul><li>With nonobject databases, place a separate layer of software between your object model and your database model. </li></ul><ul><li>Object databases both help and hinder. </li></ul>
  11. 14. Changing Interfaces <ul><li>There is no problem changing a method name if you have access to all the code that calls that method. </li></ul><ul><li>There is a problem only if the interface is being used by code that you cannot find and change. </li></ul><ul><li>Don't publish interfaces prematurely. Modify your code ownership policies to smooth refactoring. </li></ul>
  12. 15. Design Changes That Are Difficult to Refactor <ul><li>How difficult would it be to refactor from one design into another? </li></ul><ul><ul><li>Pick the simplest design if it seems easy. </li></ul></ul><ul><ul><li>Otherwise put more effort into the design. </li></ul></ul>
  13. 16. Refactoring and Design <ul><li>Refactoring can be an alternative to upfront design. </li></ul><ul><li>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 </li></ul><ul><li>An important result of this change in emphasis is a greater movement toward simplicity of design. </li></ul>
  14. 17. Refactoring and Performance <ul><li>A common concern with refactoring is the effect it has on the performance of a program. </li></ul><ul><li>Three general approaches to writing fast software: </li></ul><ul><ul><li>time/footprint budget for resources </li></ul></ul><ul><ul><li>constant attention approach </li></ul></ul><ul><ul><li>performance improvement </li></ul></ul>
  15. 18. Where Did Refactoring Come From? <ul><li>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. </li></ul>