This document discusses using metrics to identify areas of code that need refactoring. It outlines some common metrics like lines of code, number of defects, and cyclomatic complexity. While metrics can help identify problem areas objectively, they must be easy to understand and provide actionable data. Refactoring involves small incremental changes that improve code quality without changing external behavior. Code smells indicate areas that would benefit from refactoring, and metrics can help identify smelly code. Sample refactors are also discussed.

1. Metric Driven Refactoring

2. Metrics
• The Bad
• The Good
• The Compromise

3. The Bad
• Often misleading
• Often misunderstood
• Lines of Code
• Number of Defects
• Turn time

4. The Good
• Can add objectivity to a
subjective exercise
• Can help us focus on
problem areas
• Can provide guidance at
an early stage

5. The Compromise
• Metrics must be easily
understood
• Metrics must provide
actionable data
• Metric must be easy to
calculate

6. What is Refactoring
• Small incremental
changes
• Changes the internal
structure
• Does not change the
external behavior

7. Why Refactor
• Improve maintainability
• Improve performance
• Improve legibility
• Make code reusable
• Pay off design deficit

8. Code Smells
• Indicate that something
maybe wrong with code
• Smells point to the
need to refactor
• Individual smells are
often associated with
specific refactors

9. Sample Code Smells
• Long method
• Feature Envy
• Switch Statement Smell
• Shot Gun Surgery
• Large Class
• Comments

10. Smelly Metrics
• Metrics that Help
identify Code in need of
Refactoring
• Metric provides discrete
values that can be
compared against
guidelines

11. Instruction Count
• Number of IL
Instructions in a
Method
• More instructions =
Longer Method
• More Instructions =
Less Focused Method
• More Instructions =
More Effort to Support

12. Cyclomatic Complexity
• Number of Logical Paths
Through a Method
• Number of Test Cases
Needed for Full
Coverage
• Higher Complexity =
More Difficult to
Support
• Higher Complexity =
More likely to Have
Errors

13. Guidelines
• Guidelines – Not Hard
and Fast Rules
• Exceptions Allowed but
Must be Understood
• 200 Instructions per
Method or Less
• Cyclomatic Complexity
below 10
• Cyclomatic Complexity
= 1 in a View

14. Running Metrics

15. Common Refactors
• Extract Method
• Replace Method with
Method Object
• Decompose Conditional

16. Apply Some Refactors

17. New Best Practices
• Review Metrics Before
and After Each Round of
Code Changes
• “Do No Harm”
• Improve the Methods
that You Touch
• Adhering to these
Guidelines will Create
Better Software

18. Where to Get More Information
• http://www.geekswithb
logs.net/nharrison
• http://www.simple-
talk.com/author/nick-
harrison/
• http://www.refactoring.
com/catalog/index.html
• http://www.red-
gate.com/products/refl
ector/index.htm