1+ ---
2+ description: Refactoring by Martin Fowler
3+ globs: .java
4+ alwaysApply: false
5+ ---
6+ # Refactoring by Martin Fowler
7+
8+ ## Steps
9+
10+ 1. Test, change in small and repeat
11+ 2. Class methods should use data from itself and not other classes(Extract method and move method)
12+ 3. Avoid local temporary variables - it tends to increase compexity and long code
13+ 4. Instead of conditions use polymorphism(Replace conditional with polymorphism)
14+
15+ ## Avoid refactor
16+
17+ 1. When close to deadline
18+ 2. When writing from scratch is more efficient
19+
20+ ## Refactor and Design
21+
22+ 1. Always design for current problem - simplified design
23+ 2. If extensions come later on - refactor
24+
25+ ## Refactoring and Performance
26+
27+ 1. Refactoring slows down the code, but well structured code can be easily optimized later on
28+ 2. Dont optimise without measurement
29+ 3. Three kinds
30+ 1. Budgeting
31+ 2. Optimizing all along - constant attention - most of the optimizations are wasted as 90% performance hit is in small code ususally
32+ 3. Optimize at the end by running profiler and measuring and identifying bottleneck code
33+ 4. Ref - McConnel on performance
34+
35+ ## Bad smells in the code
36+
37+ 1. Duplicated Code
38+ 2. Long method
39+ 3. Large class
40+ 4. Long parameter list
41+ 5. Divergent change
42+ 1. Any change to incorporate a enhancement should change only one method in a class
43+ 6. Shotgun change
44+ 1. One change many changes in multiple classes
45+ 7. Feature envy
46+ 1. Methods should use data from its own class or atleast most of the data.
47+ 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.
48+ Usually data and methods are changing together, but not always like in these two patterns.\
49+ 8. Data clumps
50+ 1. Group data items appearing together in multiple place - into a class
0 commit comments