SlideShare ist ein Scribd-Unternehmen logo
1 von 18
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

Weitere ähnliche Inhalte

Ähnlich wie Metric driven refactoring

Clean code presentation
Clean code presentationClean code presentation
Clean code presentationBhavin Gandhi
 
Code qualityCode qualityCode quality.pptx
Code qualityCode qualityCode quality.pptxCode qualityCode qualityCode quality.pptx
Code qualityCode qualityCode quality.pptxSanjarMadraximov
 
Refactoring Legacy Code - true story
Refactoring Legacy Code - true storyRefactoring Legacy Code - true story
Refactoring Legacy Code - true storyAki Salmi
 
Cleaning Code - Tools and Techniques for Large Legacy Projects
Cleaning Code - Tools and Techniques for Large Legacy ProjectsCleaning Code - Tools and Techniques for Large Legacy Projects
Cleaning Code - Tools and Techniques for Large Legacy ProjectsMike Long
 
Code Review
Code ReviewCode Review
Code ReviewDivante
 
Code refactoring
Code refactoringCode refactoring
Code refactoringLalit Kale
 
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...Justin Gordon
 
Effective code reviews
Effective code reviewsEffective code reviews
Effective code reviewsnextbuild
 
Testing, a pragmatic approach
Testing, a pragmatic approachTesting, a pragmatic approach
Testing, a pragmatic approachEnrico Da Ros
 
Agile Israel 2017 bugs zero by Arlo Belshee
Agile Israel 2017 bugs zero by Arlo BelsheeAgile Israel 2017 bugs zero by Arlo Belshee
Agile Israel 2017 bugs zero by Arlo BelsheeAgileSparks
 
Writing acceptable patches: an empirical study of open source project patches
Writing acceptable patches: an empirical study of open source project patchesWriting acceptable patches: an empirical study of open source project patches
Writing acceptable patches: an empirical study of open source project patchesYida Tao
 
Requirements engineering for agile methods
Requirements engineering for agile methodsRequirements engineering for agile methods
Requirements engineering for agile methodsSyed Zaid Irshad
 
Adding Another "M" to MVC: MVCM
Adding Another "M" to MVC: MVCMAdding Another "M" to MVC: MVCM
Adding Another "M" to MVC: MVCMMario Vargas
 

Ähnlich wie Metric driven refactoring (20)

Clean code presentation
Clean code presentationClean code presentation
Clean code presentation
 
Code Review for iOS
Code Review for iOSCode Review for iOS
Code Review for iOS
 
Code qualityCode qualityCode quality.pptx
Code qualityCode qualityCode quality.pptxCode qualityCode qualityCode quality.pptx
Code qualityCode qualityCode quality.pptx
 
Refactoring Legacy Code - true story
Refactoring Legacy Code - true storyRefactoring Legacy Code - true story
Refactoring Legacy Code - true story
 
Cleaning Code - Tools and Techniques for Large Legacy Projects
Cleaning Code - Tools and Techniques for Large Legacy ProjectsCleaning Code - Tools and Techniques for Large Legacy Projects
Cleaning Code - Tools and Techniques for Large Legacy Projects
 
Code Review
Code ReviewCode Review
Code Review
 
Code refactoring
Code refactoringCode refactoring
Code refactoring
 
Ruby code smells
Ruby code smellsRuby code smells
Ruby code smells
 
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
Rails Conf 2014 Concerns, Decorators, Presenters, Service-objects, Helpers, H...
 
Effective code reviews
Effective code reviewsEffective code reviews
Effective code reviews
 
Refactoring
RefactoringRefactoring
Refactoring
 
Testing, a pragmatic approach
Testing, a pragmatic approachTesting, a pragmatic approach
Testing, a pragmatic approach
 
Eurosport's Kodakademi #2
Eurosport's Kodakademi #2Eurosport's Kodakademi #2
Eurosport's Kodakademi #2
 
Code Reviews
Code ReviewsCode Reviews
Code Reviews
 
Agile Israel 2017 bugs zero by Arlo Belshee
Agile Israel 2017 bugs zero by Arlo BelsheeAgile Israel 2017 bugs zero by Arlo Belshee
Agile Israel 2017 bugs zero by Arlo Belshee
 
Writing acceptable patches: an empirical study of open source project patches
Writing acceptable patches: an empirical study of open source project patchesWriting acceptable patches: an empirical study of open source project patches
Writing acceptable patches: an empirical study of open source project patches
 
mehdi-refactoring.pptx
mehdi-refactoring.pptxmehdi-refactoring.pptx
mehdi-refactoring.pptx
 
Clean Code
Clean CodeClean Code
Clean Code
 
Requirements engineering for agile methods
Requirements engineering for agile methodsRequirements engineering for agile methods
Requirements engineering for agile methods
 
Adding Another "M" to MVC: MVCM
Adding Another "M" to MVC: MVCMAdding Another "M" to MVC: MVCM
Adding Another "M" to MVC: MVCM
 

Mehr von Nick Harrison

Revisiting refactoring
Revisiting refactoringRevisiting refactoring
Revisiting refactoringNick Harrison
 
Refactoring workshop
Refactoring workshopRefactoring workshop
Refactoring workshopNick Harrison
 
Developer power tools
Developer power toolsDeveloper power tools
Developer power toolsNick Harrison
 
Revisiting Refactoring
Revisiting RefactoringRevisiting Refactoring
Revisiting RefactoringNick Harrison
 
Reflecting On The Code Dom
Reflecting On The Code DomReflecting On The Code Dom
Reflecting On The Code DomNick Harrison
 
Refactoring Workshop
Refactoring WorkshopRefactoring Workshop
Refactoring WorkshopNick Harrison
 
The Nature Of Patterns
The Nature Of PatternsThe Nature Of Patterns
The Nature Of PatternsNick Harrison
 
Adaptive Architecture
Adaptive ArchitectureAdaptive Architecture
Adaptive ArchitectureNick Harrison
 

Mehr von Nick Harrison (9)

Revisiting refactoring
Revisiting refactoringRevisiting refactoring
Revisiting refactoring
 
Refactoring workshop
Refactoring workshopRefactoring workshop
Refactoring workshop
 
Introducing fx cop
Introducing fx copIntroducing fx cop
Introducing fx cop
 
Developer power tools
Developer power toolsDeveloper power tools
Developer power tools
 
Revisiting Refactoring
Revisiting RefactoringRevisiting Refactoring
Revisiting Refactoring
 
Reflecting On The Code Dom
Reflecting On The Code DomReflecting On The Code Dom
Reflecting On The Code Dom
 
Refactoring Workshop
Refactoring WorkshopRefactoring Workshop
Refactoring Workshop
 
The Nature Of Patterns
The Nature Of PatternsThe Nature Of Patterns
The Nature Of Patterns
 
Adaptive Architecture
Adaptive ArchitectureAdaptive Architecture
Adaptive Architecture
 

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
  • 15. Common Refactors • Extract Method • Replace Method with Method Object • Decompose Conditional
  • 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