Hola,  thank  you  for  having  me  here  today!  I’m  going  to  be  telling  you  a  story,  my  story.  I  hope  you  get  something  out  of  it,  and  if  not  I  hope  it  amuses  you.  Before  I  tell  you  about  myself,  I’m  going  to  ask  you  some  ques>ons.  I  know!  Audience  par>cipa>on  at  a  soBware  conference,  how  awful  of  me!  And  just  before  lunch  too!  Don’t  worry  they  are  not  ques>ons  about  food!    Also,  everyone  has  heard  the  term  “code  smell  before  right?”  

1  

Just  for  fun,  how  many  of  you  are  rock  climbers?  

2  

Like  Rails!  Especially  ones  that  follow  or  teach  us  maintainable  paNerns  and  prac>ces  of  ways  to  structure  code.    

3  

What  is  at  the  end  of  the  Road?  What’s  the  light  at  the  end  of  the  tunnel?    I  love  descrip>ve  analogies,  especially  ones  that  come  with  a  picture  of  a  dog!    So  which  is  it?  I  think  I  made  this  preNy  obvious,  but  just  in  case.  

4  

What  is  this?  This  is  my  story.  I’m  going  to  be  telling  you  about  my  experiences  with  code,  the  Good,  the  Bad  ,and  the  Goofy!  This  explains  my  ques>ons.  I  was  wondering  who  out  there  has  a  similar  background  to  mine.    I  went  to  university  for  computer  science,  I  worked  as  a  business  consultant  doing  custom  development  in  the  MicrosoB  stack,  and  now  I  work  as  the  lead  Ruby  developer  for  Blue  Box  Group.  I’ve  worked  with  lots  and  lots  of  code  of  different  varie>es,  and  each  of  the  three  different  places  where  I  have  wriNen  and  had  to  maintained  code  I’ve  learned  something  different  about  what  makes  for  good  code  and  what  makes  for  bad  code.  Using  my  hound  sniffing  analogy,  you  can  say  my  code  sniffing  ability  grew  with  each  step  of  my  journey.    

5  

At  university  I  did  a  lot  of  java  and  C  programming  Though  we  were  using  java  to  learn  about  objects,  most  of  the  code  I  wrote  and  learned  from  was  procedural  in  nature  and  had  lots  of  condi>onals:  A  situa>on  I  like  to  refer  to  as  if-­‐else-­‐death.  Working  with  teams  was  vile,  Tests  were  unheard  of  And  I  rarely  every  looked  at  code  that  was  quote  ”finished”  –  ie:  code  for  a  completed  assignment    (in  fact  I  had  trouble  finding  code  from  that  >me  to  make  this  awful  picture  of  java  code  for  this  talk)    So  with  my  dog  analogy:  a  dog  with  a  refined  sniffer  at  this  point  would  look  at  my  code  and  need  a  gas  mask….  

6  

So  what  did  I  learn  about  code  from  University?  Of  course  I  learned  the  basics:  how  to  solve  a  programming  problem  (don’t  underes>mate  this!)  <Read  1st  bullet>  unless  I  interview  with  Google  (linked  list,  Back-­‐Tracking  Search,  Bubble  Sort,  etc…)  I  did  ACM  compe>>ons,  Top  Coder  compe>>ons,  etc…  I  certainly  got  skills  from  doing  that,  but  they  were  not  skills  about  how  to  create  maintainable,  and/or  scalable,  applica>ons.    I  was  a  CS  TA  for  3  years,  and  found  teaching  to  be  the  best  way  for  me  to  learn  myself.    (Not  really  anymore…)  I  really  loved  javadoc  when  I  got  out  of  school,  I  thought  that  was  the  best  and  only  way  to  document  code!  How  awesome  is  that,  something  creates  docs  right  from  your  comments!  HAHA  ok  enough  with  the  java  already!  This  is  a  RoR  conf!    

7  

So  what  am  I  going  to  talk  about  next?  C#...    As  a  consultant,  one  of  my  favorite  projects  was  building  a  financial  forecas>ng  system  for  a  very  large  organiza>on  from  scratch  in  C#  .Net.    It  was  a  service  oriented  web  applica>on  that  was  going  to  save  all  of  their  financial  analysts  tons  and  tons  of  >me.      We  used  the  Windows  Workflow  Founda>on  framework  for  structuring  the  app.    Anyone  familiar  with  the  WWF?  Hehe  I  like  to  refer  to  that  acronym  because  it’s  reference  to  the  world  wrestling  federa>on  is  appropriate  –  It’s  a  big  show,  and  very  few  people  get  hurt.  We  had  lots  and  lots  and  lots  of  code.  But  it  wasn’t  horrible  code,  it  was  very,  very  structured  code.    Everything  with  a  similar  purpose  was  grouped  together,  you  knew  where  to  look  for  a  par>cular  ac>on,  naming  conven>ons  and  code  paNerns  for  methods  were  strictly  enforced….  Even  when  they  didn’t  really  make  sense…..    Our  hound  in  this  picture  is  just  sneezing,  he’s  not  terribly  sick,  but  this  somewhat  nicely  paNerned  behemoth  of  code  never  actually  went  into  produc>on…      Also,  our  “test  suite”  was  actually  a  team  of  testers  with  scripts  they  would  run  through  any  >me  the  app  changed.  That  is  preNy  typical  big  corpora>on  waste  from  what  I  have  seen.  

8  

So  What  did  I  learn  about  code  here?  Consistently  adhering  to  paNerns  makes  code  wriNen  by  different  team  members  separately  adhere  together  nicely.  I  certainly  learned  about  single  responsibility  and  abstrac>ons,  but  there  were  paNerns  beaten  into  me  that  never  really  clicked:  Always  make  your  if  statements  posi>ve,  and  you  must  always  have  an  else  when  there  is  an  if.  What?  Why?  Well  now  I  can  say  I  understand  that  if  you  have  an  if,  you  are  branching  your  code,  and  puong  the  else  there  makes  that  other  branch  explicit,  therefore  giving  someone  who  comes  aBer  more  informa>on  about  what  your  code  does.  I  can  see  the  argument,  but  I  would  say  now  get  rid  of  the  branch  and  use  polymorphism  –  objects  are  your  friends!!!  But  again,  this  wasn’t  Ruby,  the  framework  wasn’t  Rails,  and  this  was  enterprise  level  business  prac>ces  –  a  much  more  restric>ve  environment  than  most  of  us  in  the  RoR  community  work  in.      

9  

So  what  was  next?  Ruby!  Rails!  Legacy  Code?  Best  way  to  understand  OO  design  principles  is  to  work  with  code  that  doesn’t  follow  any.    But  it’s  a  rails  app,  it  has  MVC  structure  and  separa>on  of  concerns  at  those  layers,  right?  The  model  I’ve  excerpted  here  has  2,533  lines    The  dog  in  this  picture  says  it  all….    So  what  do  you  do?  This  is  produc>on  code,  that  the  business  and  the  customers  depend  on.  There  are  bugs.  (Did  I  really  need  to  say  that?)  but  really  there  are  bugs  that  need  fixing  and  feature  requests  that  need  implementa>on.  You  goNa  deal  with  it,  you  goNa  do  it  –  That’s  how  I  learned  to  smell  code.  

10  

make  sure  there  are  tests!  –  Get  the  business  requirements  (AGAIN)  from  the  end  user  –  if  it  works  in  produc>on  that  does  not  mean  “don’t  change  it”,  that  means  “Good  the  end  users  know  the  business  process,  and  we  can  easily  re-­‐capture  what  this  cluster  is  trying  to  do,  and  re-­‐do  it  beNer”.  

11  

All  of  my  first  code  looks  like  C#,  because  that’s  the  last  language  I  knew,  and  there  weren’t  any  good  paNerns  to  follow.  I  fought  with  Rails  about  how  it  structures  data  –  I’m  a  db  girl,  who  all  of  a  sudden  isn’t  supposed  to  worry  about  the  database  anymore….  When  I  found  myself  wri2ng  just  as  nasty  (in  terms  of  maintainability)  code  I  looked  for  help.    

12  

13  

Rails  paNerns  are  geong  beNer  and  beNer:  Coffee  Script  –  makes  our  js  less  smelly  –  and  there  will  be  emerging  new  paNerns  here  for  maintaining  all  the  gobs  of  client  side  code  we  are  all  wri>ng  

14  

I  talked  about  paNerns  to  follow  –  here  I’m  talking  about  not  following  a  paNern  –  when  you  follow  an  an>-­‐paNern  you  will  learn  something  –  work  with  someone  else  who  has  a  different  paNern  and  learn  together  with  them.  The  least  smelly  programmers  are  pair-­‐programmers  

15  

If  you  have  never  seen  the  anit-­‐paNerns  or  code-­‐smells  talked  about  here,  they  may  not  click,  but  then  re-­‐read  it.  This  is  a  reference  manual,  not  a  one-­‐>me-­‐read.  

16  

Same  idea  here  –  this  book  is  men>oned  in  Clean  Code  –  read  all  the  books  in  clean  code’s  bibliography  –  I  have  not  goNen  through  all  of  them  yet.  

17  

Lastly  –  pick  up  a  hobby  –  you  learn  really  cool  things  about  what  you  do  everyday  when  you  do  something  else.      From  Rock  climbing  I’ve  learned  this  about  OO  design  paNerns:  It’s  like  learning  to  belay  –  you  learn,  you  become  a  good  belayer,  It  becomes  muscle  memory,  but  you  don’t  really  get  it,  un>l  one  day  it  clicks  –  you’ve  caught  lots  of  falls,  you’ve  both  lead  climbed  and  caught  a  leader  fall  –  you  get  how  the  system  works  and  why  the  paNern  /  the  rules  you  follow  are  there.  That  is  when  you  can  evolve  and  modify  the  system.  You  know  when  to  follow  the  paNern  and  when  to  improvise.      Do  this  with  your  code  and  help  others  do  it  –  follow  a  couple  good  design  paNerns,  make  them  muscle  memory,  and  one  day  it  will  click,  and  then  you  can  evolve  your  own  paNerns  that  will  push  the  field  forward.  –  If  you’ve  followed  lots  of  good  paNerns,  you  will  know  how  to  make  a  good  new  one.  

18  

Not  everyone  has  the  same  experiences  you  do,  some>mes  you  need  to  write  a  bit  of  C#  in  ruby  to  figure  out  that  ruby  shouldn’t  be  wriNen  that  way.    I’ve  found  that  these  three  things  that  are  about  learning  and  flexibility  are  more  important  to  crea>ng  scentless  code  than  anything  else.    For  #  4  :  It’s  my  pet  peeve  –  I’m  allowed  one  soap-­‐box  per  talk,  and  this  is  it.  every  point  in  Chapter  17  (smells  and  heuris>cs)  that  is  made  about  comments  is  100%  true.  I’ve  seen  all  of  them,  I’ve  done  a  number  of  those  things  with  comments  myself.    JUST  STOP!  Make  your  code  document  itself,  no  one  who  comes  aBer  you,  who  changes  what  your  code  does,  will  update  your  comments,  but  they  will  update  your  names  and  method  signatures.    And  trust  your  source  control  –  use  Git  for  your  comments  –  it’s  a  much  beNer  place  for  them.  All  of  us  think  about  the  appropriate  place  for  our  code  to  go,  think  about  the  appropriate  place  for  your  comments.  

19  

20