Developer Job in Practice Clean code rules • Code review • Refactoring

Kamil Kowalski kamil.kowalski@blstream.com

2  

Being a developer

!  You  need  to  follow  the  rules,  wheter  they  are  

!  You should ask the questions – especially in case of doubts

!  You should learn new things: all the time, always and also from others !  ... till end (of time)

Developer’s job is not only about developing the code

!  It  would  be  great  to  have  a  leader:    !  to  learn  from  !  to  follow    

!  You  are  the  team  player    

!  You  work  with  legacy  systems  

3  

Typical project setup

!  Waterfall,  Agile,  ...  !  How project is run:

!  Scrum !  Kanban !  Programin Mother*ker

!  Developing the code !  Code first !  TDD !  „Who needs unit tests” / „We don’t

test our code” ☺

There is no one! Each single project has its own setup!

!  Tools:    !  IDE  –  Xcode,  VS,  IntelliJ,  ...  !  Repository:  SVN,  Git,  ...  !  CI  environment:  Hudson,    Jenkins,  

CC.NET,...  !  Scripts:  Python,  MsBuild,  ANT,  

NANT,  ...  !  SupporQng  tools:  R#,  StyleCop    

!  Review  Tool  !  Project  board,  back  trucking:  JIRA  !  Code  guide  !  DefiniQon  of  Done  /  DefiniQon  of  

Ready  !  Build  in  one  step  &  daily  builds  

4  

Definition of Done / Definition of Ready

!  DoD / DoR says about the rules you need to follow during daily work

!  Each developer in team need to follow DoD – no exceptions!

!  Each team member need to follow DoR – no exceptions!

!  Each single project has its own DoD / DoR

DoD / DoR is our contract! !  Sample DoD: !  All unit tests passed !  All integration tests passed !  No warnings in code (also warnings

from StyleCop) !  Code coverage over 91% !  Max cyclomatic complexity below 12 !  Build passed on CI server

!  Sample DoR: !  Functionality working (all AC’s met) !  Unit test written !  Code approved by 2 other developers !  QA accepted !  Functionality available on CI staging

environment !  Documentation updated

5  

Code smells

!  Duplicated Code !  Long Method !  Large Class !  Long Parameter List / too many

of them !  Switch Statement !  Temporary Field !  Magic numbers !  Naming !  Complex Conditionals !  Dead code

If it stinks, change it! !  High quality code is: !  Easy  to  read  and  understand  !  Impossible  to  hide  bugs  !  Easy  to  extend  !  Easy  to  change  !  Has  unit  tests    

!  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

public  class  Record_Base  {          public  DateTime  RecordDateTime          {                  get  {  return  _recordDateTime;  }                  set                        {                            if  (this.GetType().Name  ==  "Record_PartRegister")    _recordDateTime  =  value;                        else                                      throw  new  ExcepQon("Cannot  call  set  on  RecordDateTime  for  table  "  +  this.GetType().Name);                  }          }  }  

h\p://thedailyw].com/ArQcles/Making-­‐Off-­‐With-­‐Your-­‐Inheritance.aspx  

This is not OOP!

KISS my DRY and SOLID code

7  

Simple rules for developers – how to write the code

!  Keep It Simple -Stupid

!  Don’t Repeat Yorself

!  Uncle Bob Clean Code(r)

!  SOLID  principles:    !  Single  Responsibility  

Every  object  should  have  a  single  responsibility,  and  that  responsibility  should  be  en7rely  encapsulated  by  the  class.  

!  Open  /  Closed  principle  So:ware  en77es  (classes,  modules,  func7ons,  etc.)  should  be  open  for  extension,  but  closed  for  modifica7on.  

!  Liskov  SubsQtuQon  Objects  in  a  program  should  be  replaceable  with  instances  of  their  subtypes  without  altering  the  correctness  of  that  program.    

!  Interface  SegragaQon  Clients  should  not  be  forced  to  depend  on  methods  they  do  not  use.  

!  Dependency  Inversion  Abstrac7ons  should  not  depend  on  details.    Details  should  depend  on  abstrac7ons.  

8  

Code reviews

!  Can  catch  up  to  60%  of  defects  !  EffecQve  code  reviews  are:  

!  Short  –  don’t  waste  Qme  !  ConstrucQve  !  Avoid  emoQonally  draining  arguments    

!  Code  review  rules  depend  on  project  you’re  working  on  -­‐  samples:  !  Banking  system    -­‐  SOLID,  security    !  NASA    !  Games  -­‐  opQmizaQon  ,  code  efficiency,  don’t  

care  about  excepQons    !  Mobile  applicaQon  –  SOLID,  but  efficiency    

Everybody reviews and everybody is reviewed.

!  Rules:  !  Syntax  !  !  Code  Style  –  be  project  StyleCop  

(naming)  !  Simplicity  !  DRY  violaQons  !  SOLID  violaQons  !  Security  –  buffers,  stack  overflow,  input  

dfata  sanity  (trust  no  one),  cross  boarders  (SQL  injecQon,  XSS)  

!  Memory  leaks  !  OpQmizaQon  -­‐  code  efficiency  !  Strings  !  

 

9  

Why should I refactor?

!  Technical  what?!  -­‐  is  a  metaphor:    

!  doing  things  the  quick  and  dirty  way  sets  us  up  with  a  technical  debt,  which  is  similar  to  a  financial  debt  

!  incurs  interest  payments,  which  come  in  the  form  of  the  extra  effort  that  we  have  to  do  in  future  development.  

!  Refactoring  is  changing  the  structure,  but  not  the  funcQonality  of  your  applicaQon.  

 

Refactoring is our way of paying off our “Technical Debt”

!  How  Should  I  Refactor:  !  Ask  yourself  the  following  quesQons:  

!  Is  my  code  readable?  !  Is  my  code  abstract?    

!  Anything  more  is  rearranging  the  deck  chairs  on  the  Titanic:  !  It  gives  you  a  sense  of  doing  something  !  But  ulQmately  it’s  pointless    #  

!  Follow  the  rules:    !  KISS  /  DRY  /  SOLID  !  Clean  code  !  Code  review  rules!    

•  Refactoring  catalogs:  h\p://www.refactoring.com/catalog/index.html    

•  Refactoring  (book)  h\p://www.amazon.co.uk/Refactoring-­‐Improving-­‐Design-­‐ExisQng-­‐Technology/dp/0201485672/ref=sr_1_1?ie=UTF8&s=books&qid=1246371771&sr=8-­‐1    

Resources