RubyConf Uruguay 2011

864 views

Published on

Talk given in Montevideo in 2011 for 30mins.

Focussing on code quality and understanding what that means.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
864
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

RubyConf Uruguay 2011

  1. 1. Ola.  
  2. 2. @nigelfds   github.com/nigelfds  
  3. 3. (Talk  +  Examples)  ~  1hour  (Talk  –  Examples)  ~  30mins  
  4. 4. Refactoring?  
  5. 5. a  change  made  to  the  internal  structure  of  soFware  to  make  it  easier  to  understand  and  cheaper  to  modify  without  changing  its  observable  behavior   -­‐  MarLn  Fowler  
  6. 6.  Dont  touch  anything  that  doesnt   have  coverage.  Otherwise,  youre  not  refactoring;   youre  just  changing  shit.  
  7. 7. a  change  made  to  the  internal  structure  of  soFware  to  make  it  easier  to  understand  and  cheaper  to  modify  without  changing  its  observable  behavior   -­‐  MarLn  Fowler  
  8. 8. SomeLmes    it  just  feels   right.  
  9. 9. Step  1:  Measure  the   toxicity.  
  10. 10. Smells  in  the  code  
  11. 11. CyclomaLc  Complexity  5  to  7  is  decent  for  most  ruby  code  
  12. 12. Saikuro  
  13. 13. Assignments,  Branches,  Calls     with  Flog  Watch  for  scores  greater  than  40  
  14. 14. Flog  
  15. 15. DuplicaLon  with  Flay  Watch  for  scores  greater  than  30  
  16. 16. Flay  
  17. 17. Control  Couples  and  more     with  Reek  Simulated  Polymorphism  Feature  Envy  ULlity  Methods  
  18. 18. LinLng  with  Dust/Nitpick  Branch  Checks  
  19. 19. Common  smells     in  Ruby    
  20. 20. PrimiLve  Obsession  
  21. 21. Feature  Envy  class Cart def price @item.price + @item.tax endend
  22. 22. Meta-­‐programming   Keep  it  simple.     Keep  it  declaraLve  
  23. 23. Toxicity  is  more  than  code  smells  
  24. 24. “The  real  problem  I  have  with  the  CK  suite  and  similar  metrics  is  that  they  only  measure  a  single  module  (or  class  in  this  case).    I  claim  that  the  quality  of  the  design  of  a  system  is  not  something  that  can  be  determined  by  looking  at  individual  classes.    It  is  conceivable  that  every  class  in  a  system  could  be  considered  reasonable  by  whatever  single-­‐class  metrics  are  being  used,  but  the  overall  design  is  considered  bad.”  Ewan  Tempero:  A  Research  Agenda   hDp://www.cs.auckland.ac.nz/~ewan/  
  25. 25. Duplicity  vs  Coupling  
  26. 26. DEPENDENCY  
  27. 27. Tangles  
  28. 28. Step  2:  Make  it  visible  
  29. 29. Treemaps  (Max  CC)  hbp://mbostock.github.com/protovis/  
  30. 30. Treemaps  
  31. 31. Dependency  matrix  
  32. 32. Step  3:  Agree  on  the  fix  
  33. 33. Step  4:      Go  fix  it  
  34. 34. “I  do  believe  that  complexity  is  the  enemy.  UnKl  we  beDer  understand  complexity,  our  chances  of  building  beDer  IT  systems  is  limited.  The  first  thing  we  must  understand  about  complexity  is  that  not  all  complexity  is  equal.  And  the  complexity  on  which  most  people  focus  is  probably  the  least  complex  complexity  of  all.”  Roger  Sessions   hbp://simplearchitectures.blogspot.com/2009/03/cancer-­‐of-­‐complexity.html  
  35. 35. Gracias  

×