Reasons to refactor: 1. Code is duplicated.2. A ring is to 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 data16. A Middleman Object isn't doing anything.17. One class is overly intimate with another.18. A Routine Has a poor name.19. Data mebers Are Public.20. A Subclass Uses Only A Small Percentage of Its Parents' Routines.21. Comments Are Used to Explain Diffic Ult 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 Seem 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 with2. 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 case.9. Review the change. Adjust your approach depending on the risk level of the refactoring.
Bad time to refactor1. Do not 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.
