An Empirical Study of Design Degradation: How Software Projects Get Worse Over Time

An Empirical Study of Design Degradation: How Software Projects Get Worse Over Time

ESEM2015

7054e88c483431e1c8ed017fc650c8c2?s=128

Iftekhar Ahmed

October 22, 2015
Tweet

Transcript

  1. An Empirical Study of Design Degradation: How Software Projects Get

    Worse Over Time I"ekhar Ahmed, Umme Ayda Mannan, Rahul Gopinath, Carlos Jensen October 22, 2015
  2. What this paper is about •  Large longitudinal study of

    code smells in open source projects •  Confirms and quanIfies what many assume to be true •  Corrects some misconcepIons •  Adds new details about how designs degrade July 15, 2016 1
  3. What is a Code Smell 2 •  Neither syntax errors

    nor compiler warnings. •  Bad program design or bad coding pracIce. •  Duplicate code •  High CyclomaIc complexity •  Code smells are associated with •  Maintainability [Fowler 2002] •  Bugs [Oliva et al. 2013] •  Design debt [Izurieta & Bieman 2007] October 22,2015
  4. Introduction 3 Project characteris-cs Code smell Longevity of project Decreased

    number of code smells Number of core developers Increased number of code smells Frequency of code changes Increased number of code smells Number of files in code base Increased number of code smells October 22,2015 Previous studies have shown relaIonships like:
  5. Introduction 4 But how do code smells evolve? Do these

    findings hold over a large sample of projects? Project characteris-cs Code smell Longevity of project Decreased number of code smells Number of core developers Increased number of code smells Frequency of code changes Increased number of code smells Number of files in code base Increased number of code smells October 22,2015 Previous studies have shown relaIonships like:
  6. Research questions •  How do code bases evolve over Ime

    wrt. code smells? •  Who addresses technical debt (code smells)? •  Is there a correlaIon between testedness and smellyness? •  Are we focusing on the smells coders struggle with? 5 October 22,2015
  7. Methodology July 15, 2016 6

  8. Methodology 7 October 22,2015 220 Projects Cap at 200 wks

    33,070 commits 3,426 smells Analysis Randomly selected top 500 Java projects using Maven from Github •  10+ weeks of history •  500+ lines of code •  10+ files •  Could be successfully built
  9. Methodology 8 October 22,2015 220 Projects Cap at 200 wks

    33,070 commits 3,426 smells Analysis To remove the long tail, capped commit data at 200 weeks •  Threw out 5% of the commit data
  10. Methodology 9 October 22,2015 220 Projects Cap at 200 wks

    33,070 commits 3,426 smells Analysis For each commit to each project •  Calculate # of code smells at that point in Ime •  Calculate test coverage metrics (statement, branch & path) Within project metrics
  11. Methodology 10 October 22,2015 220 Projects Cap at 200 wks

    33,070 commits 3,426 smells Analysis Mapped smells to higher-level categories
  12. Methodology 11 October 22,2015 220 Projects Cap at 200 wks

    33,070 commits 3,426 smells Analysis Normalized results to allow inter-project comparisons •  0-1 mapping, 0=min count, 1=max count
  13. Findings July 15, 2016 12

  14. How code smells evolve 13 Week-wise average project smelliness October

    22,2015
  15. Some grow continuously 14 October 22,2015 Bloater smells

  16. Others plateau… or dip 15 October 22,2015 OO abusers

  17. How code smells evolve 16 Week-wise average project smelliness October

    22,2015
  18. Commits introducing or removing smells 17 October 22,2015

  19. Who removes code smells? 18 October 22,2015 10% of developers

    responsible for removing most smells
  20. Testing does not correlate with smell removal 19 October 22,2015

  21. Research vs. Practice 20 October 22,2015 0 5 10 15

    20 Data Clumps Data Class Cyclic Dependencies Blob OperaIon DuplicaIon Feature Envy SAP Breakers God Class Intensive Coupling Schizophrenic Class Blob Class Unstable Dependencies TradiIon Breaker Refused Parent Bequest Message Chains Shotgun Surgery Distorted Hierarchy UnnecessaryCoupling Rank From Literature From Projects More Important (Practitioner)
  22. Conclusions •  Projects get smellier over Ime •  But not

    all smells created equal? •  Is this true for non open source projects as well? •  A small set of core contributors responsible for fixing smells, but not keeping up •  TesIng and refactoring do not go hand in hand •  Though coverage and some smells correlated •  Is it done by the same people though? •  PotenIal mismatch between interesIng smells and common smells •  May hinder interest and adopIon of code smell tools 21 October 22,2015
  23. Thank you May 08,2014 22