Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Software metrics

Software metrics

When designing a bridge, an architect has al sorts of tools & techniques to verify it won't collapse.

Us software developers... We build. And with a bit of luck, we'll even test. And then we pray it doesn’t collapse :)

Can we measure software? Can we compare code objectively? Can we predict problems?

Matthias Mullie

May 17, 2016
Tweet

More Decks by Matthias Mullie

Other Decks in Programming

Transcript

  1. Every code path adds complexity Counts # of code paths

    Software metrics » Complexity Cyclomatic complexity
  2. • Analyze control flow • Start at 1 • Increase

    at every decision path
 (if, for, case, …) Software metrics » Complexity Cyclomatic complexity
  3. if ($user->isLoggedIn()) { echo 'Welcome back, ' . $user->getName(); }

    else { echo 'Hi there, stranger!'; } Cyclomatic complexity = 2 Software metrics » Complexity Cyclomatic complexity
  4. Software metrics » Complexity NPath complexity if ($user->getSalutation()) { echo

    $user->getSalutation().' '; } if ($user->getName()) { echo $user->getName(); } else { echo 'anon'; } Outcomes: • $salutation anon • anon • $salutation $name • $name
  5. • Analyze vocabulary • Count amount of operators
 (+, -,

    =, &&, ... and reserved words,
 like if and for) • Count amount of operands
 (values, variables & function names) Software metrics » Complexity Halstead measures
  6. if ($user->isLoggedIn()) { echo 'Welcome back, ' . $user->getName(); }

    else { echo 'Hi there, stranger!'; } Operands = 4 (4 unique) Software metrics » Complexity Halstead measures
  7. if ($user->isLoggedIn()) { echo 'Welcome back, ' . $user->getName(); }

    else { echo 'Hi there, stranger!'; } Operators = 11 (7 unique) Software metrics » Complexity Halstead measures
  8. Combination of: • Cyclomatic complexity • Halstead measures • Lines

    of code Software metrics » Complexity Maintainability index
  9. Amount of incoming dependencies = other classes using this one

    Common for core functionality Software metrics » Coupling Afferent coupling
  10. class Afferent { function __construct() {} } class Efferent {

    function __construct(Afferent $a) {} } Afferent: 1, Efferent: 0 Software metrics » Coupling Afferent coupling
  11. Changes here may break things elsewhere Must be stable &

    thoroughly tested Software metrics » Coupling Afferent coupling
  12. Amount of outgoing dependencies = other classes being used Common

    for controllers Software metrics » Coupling Efferent coupling
  13. class Afferent { function __construct() {} } class Efferent {

    function __construct(Afferent $a) {} } Afferent: 0, Efferent: 1 Software metrics » Coupling Efferent coupling
  14. • Harder to read/maintain • Harder to reuse • Harder

    to test in isolation • Brittle Software metrics » Coupling Efferent coupling
  15. Changes elsewhere may break things here Probably violates single responsibility

    principle Software metrics » Coupling Efferent coupling
  16. = efferent coupling / total coupling = efferent coupling /

    (efferent + afferent) Resilience to change Software metrics » Coupling Instability
  17. High efferent coupling = likely to be impacted by changes

    in
 = other classes = not stable Software metrics » Coupling Instability
  18. Low afferent coupling = change is easy because there isn’t

    much
 = that depends on this = not stable Software metrics » Coupling Instability
  19. Stable = good … as long as you don’t need

    to change the implementation! Software metrics » Coupling Instability
  20. Aim for extremes, make classes as stable or unstable as

    possible! Unstables can be refactored/decomposed later. Better than having dependencies everywhere. Software metrics » Coupling Instability
  21. class Ancestor {} DIT: 0 class Descendant1 extends Ancestor {}

    DIT: 1 class Descendant2 extends Descendant1 {} DIT: 2 Software metrics » Coupling Depth of inheritance
  22. Inheritance is not bad! • Code reuse • Polymorphism Software

    metrics » Coupling Depth of inheritance
  23. But too much is! • Less stable: change in ancestor

    can affect descendants • More complexity: methods of all ancestors are inherited Software metrics » Coupling Depth of inheritance
  24. It’s not too crazy! But: • Recursion • 3 loops

    • 4 conditions • Callback function Software metrics » Usage Complexity
  25. Method does too much: • Data transformation • Processing •

    Cleanup Hard to test & prove right! Software metrics » Usage Complexity
  26. Software metrics » Usage Refactoring • 1000+ LOC class •

    Pretty complex • Very unstable • Self-contained, barely reusable
  27. Software metrics » Observations Refactoring • Greatly reduced “monster class”

    • Split into multiple reusable pieces Software metrics » Usage
  28. Complexity often caused by a few commits! Watch out with

    new features & rewrites. Software metrics » Observations Spikes!
  29. • No change over time • No change across projects

    Do developers have a “signature”? Software metrics » Observations No evolution
  30. Software metrics » Observations Personalities? 2 guys working on same

    project: • One was very fast (but messier) • One was a lot more thorough Who’s who?
  31. Software metrics » Observations Personalities? Can metrics show personality traits?

    Please help me figure that out! https://www.cauditor.org/user/feedback