Refactoring by Martin Fowler

Steps

1. Test, change in small and repeat
2. Class methods should use data from itself and not other classes(Extract method and move method)
3. Avoid local temporary variables - it tends to increase compexity and long code
4. Instead of conditions use polymorphism(Replace conditional with polymorphism)

Avoid refactor

1. When close to deadline
2. When writing from scratch is more efficient

Refactor and Design

1. Always design for current problem - simplified design
2. If extensions come later on - refactor

Refactoring and Performance

• Refactoring slows down the code, but well structured code can be easily optimized later on
• Dont optimise without measurement
• Three kinds
  • Budgeting
  • Optimizing all along - constant attention - most of the optimizations are wasted as 90% performance hit is in small code ususally
  • Optimize at the end by running profiler and measuring and identifying bottleneck code
• Ref - McConnel on performance

Bad smells in the code

1. Duplicated Code
2. Long method
3. Large class
4. Long parameter list
5. Divergent change
   1. Any change to incorporate a enhancement should change only one method in a class
6. Shotgun change
   1. One change many changes in multiple classes
7. Feature envy
   1. Methods should use data from its own class or atleast most of the data.
   2. Visitor and strategy patterns and Kent Beck's Self Delegation breaks this rule. But they are valid as they are to combat Divergent change. Usually data and methods are changing together, but not always like in these two patterns.\
8. Data clumps
   1. Group data items appearing together in multiple place - into a class