img wangjiong


发表于2004/10/21 23:48:00  653人阅读

Reasons to refactor:
1. Code is duplicated.
2. A routine is too long.
3. A loop is too long or too deeply nested.
4. A class has poor cohesion.
5. A class interface does not provide a consistent level of abstraction.
6. A parameter list has too many parameters.
7. Changes within a class tend to be compartmentalized.
8. Changes require parallel modification to multiple classes.
9. Inheritance hierarchies have to be modified in parallel.
10. case statement have to be modified in parallel.
11. Related data items that are used together are not organized into calss.
12. A routine uses more features of another class than of its own class.
13. A primitive data type is overlaoded.
14. A class doesn't do very much.
15. A chain of routines passes tramp data
16. A middle man object isn't doing anything.
17. One class is overly intimate with another.
18. A routine has a poor name.
19. Data memebers are public.
20. A subclass uses only a small percentage of its parents' routines.
21. Comments are used to explain difficult code.
22. Global variables are used.
23. A routine uses setup code before a routine call or takedown code after a routine call.
24. A program contains code that seems like it might be needed someday.

Specific refactorings:
I think it's better to refer it to the book: Refactoring.

Keys to refactoring safely:
1. Save the code you start with
2. Keep refactoring small.
3. Do refactoring one at a time.
4. Make a list of steps you intend to take.
5. Make a parking lot.
6. Make frequent checkpoints.
7. Retest.
8. Add test cases.
9. Review the changes.
10. Adjust your approach depending on the risk level of the refactoring.

Bad time to refactor
1. Don't use refactoring as a cover for code and fix.
2. Avoid refactoring instead of rewriting.

Refactoring startegies.
1. Refactor when you add a routine.
2. Refactor when you add a class.
3. Refactor when you fix a defect.
4. Target error-prone modules.
5. Target high complexity modules.
6. In a maintenance environment, improve the parts you touch.
7. Define an interface between clean code and ugly code, and then move code across the interface.

0 0


取 消