Principlesinrefactoring 090906230021-phpapp01


Published on

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Principlesinrefactoring 090906230021-phpapp01

  1. 1. 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.
  2. 2. 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.
  3. 3. 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.
  4. 4. 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.
  5. 5. 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.”
  6. 6. 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."
  7. 7. Refactoring Helps You Program Faster Refactoring helps you develop software more rapidly, because it stops the design of the system from decaying.
  8. 8. When Should You Refactor? Refactor When You Add Function Refactor When You Need to Fix a Bug Refactor As You Do a Code Review
  9. 9. 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!
  10. 10. 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.
  11. 11. 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.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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
  15. 15. 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.