• Save
Metric driven refactoring
Upcoming SlideShare
Loading in...5
×
 

Metric driven refactoring

on

  • 1,351 views

 

Statistics

Views

Total Views
1,351
Views on SlideShare
1,344
Embed Views
7

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 7

http://www.slideshare.net 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Metric driven refactoring Metric driven refactoring Presentation Transcript

  • Metric Driven Refactoring
  • Metrics • The Bad • The Good • The Compromise
  • The Bad • Often misleading • Often misunderstood • Lines of Code • Number of Defects • Turn time
  • The Good • Can add objectivity to a subjective exercise • Can help us focus on problem areas • Can provide guidance at an early stage
  • The Compromise • Metrics must be easily understood • Metrics must provide actionable data • Metric must be easy to calculate
  • What is Refactoring • Small incremental changes • Changes the internal structure • Does not change the external behavior
  • Why Refactor • Improve maintainability • Improve performance • Improve legibility • Make code reusable • Pay off design deficit
  • Code Smells • Indicate that something maybe wrong with code • Smells point to the need to refactor • Individual smells are often associated with specific refactors
  • Sample Code Smells • Long method • Feature Envy • Switch Statement Smell • Shot Gun Surgery • Large Class • Comments
  • Smelly Metrics • Metrics that Help identify Code in need of Refactoring • Metric provides discrete values that can be compared against guidelines
  • Instruction Count • Number of IL Instructions in a Method • More instructions = Longer Method • More Instructions = Less Focused Method • More Instructions = More Effort to Support
  • 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
  • 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
  • Running Metrics
  • Common Refactors • Extract Method • Replace Method with Method Object • Decompose Conditional
  • Apply Some Refactors
  • 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
  • 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