Using code metrics, we can find problems in our software that make it hard for our design to change. This presentation shows an example of using complexity metrics to find a trouble spot, and a few first steps in the refactoring process.
of Demeter Loose coupling, avoid train wrecks TRUE Transparent, reasonable, usable, exemplary “Alexander, I think the Law of Demeter is shit and never follow it.” --DHH
need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children — Jake Skruggs, author of metric_fu http://jakescruggs.blogspot.com/2008/08/whats-good- og-score.html
need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children — Jake Skruggs, author of metric_fu http://jakescruggs.blogspot.com/2008/08/whats-good- og-score.html poor metrics = makes our design hard to change
Method Call Feature Envy Utility Function Irresponsible Module Long Parameter List Long Yield List Nested Iterators Simulated Polymorphism Nil Check Repeated Conditional Too Many Instance Variables Too Many Methods Too Many Statements Uncommunicative Name Unused Parameters
Detect code smells. Flay Analyzes code for structural similarities (duplication). Rails Best Practices Checks the quality of your Rails code. Brakeman A static analysis security vulnerability scanner. Cane Fails your build if code quality thresholds are not met. Simplecov Test coverage analysis.