Code reviews


Published on

How to do code review? What is the process? What to look for? How to keep a good vibe and improve the team?

These and many other questions are solved for good in this presentation.

Published in: Software, Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Code reviews

  1. Code Reviews What, why and how.
  2. -Code review is systematic examination of computer source code. ! It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills. ! Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections. Kolawa, Adam; Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. p. 260. W H AT
  3. - The most pessimistic empirical studies show that code reviews improve error detection on 60%. [Boehm and Basili 2001] citation from Glass, Robert Facts and Fallacies of Software Engineering ! McConnell, Steve Code Complete W H Y
  4. -The same studies show that the cost of inspections is less than the cost of the testing that would be necessary to find the same errors. ! Jason Cohen, Steven Teleki & Eric Brown The Case for Peer Review W H Y 100 200 300 400 500 after dev after CR after QA customer 32 113 180 463 194 321 463463 no CR $368k w/ CR $152k
  5. . .. -Code Reviews also… ! enforce accountability make people write better code in the first time spread knowledge on product, code… make developers grow by having feedback make developers desidentify with the code enhance team spirit are fun W H Y .. . .
  6. - 1 push your feature branch with your ninja code 2 send the review 3 add all relevant info to help the reviewers 4 don’t expect immediate feedback, do something else 5 reply to the comments; fix the todos
 6 never ever push without having the minimum “shipits” agreed 7 close the review L I F E C Y C L E
  7. - Must
 can’t go to production without 
 doubts about the logic, the story… ! Suggestion may be implemented on this feature on in another story, add to the backlog and reference the review C O M M E N T S . . .
  8. - 1 Time Take time to review H O W
  9. -H O W 2 Understand Try to read everything before commenting Start by unit tests if there are any Is it simple? Is it readable?
  10. -H O W 3 Basics Coding Standards Indentation Naming Simple algorithm improvements … We’ll automate most of it once we know it
  11. -H O W 4 Requirement Does the code do what is in the requirements?
  12. -H O W 5 Bigger picture Think about things the developer may not be taking into consideration Question the value
  13. -H O W 6 NIH Is the code reinventing the wheel? Are there gems/solutions out there? PFE™
  14. -H O W 7 Errors Both on logic and business
  15. -H O W 8 Security XSS SQL Injection Encryption …
  16. -H O W 9 Performance SQL Overkill DB Indexes Slow processes not in background …
  17. -H O W 10 Architecture Hardest part IMO, we’ll focus on learning that later
  18. -H O W 11 Teach Not only point, try to be didactic Share things that may not even be related to the code itself
  19. -H O W 12 Learn About software, about the project, about the people
  20. -H O W 13 Be constructive Code reviews are team work
  21. -H O W 14 Review again If you sent comments check that they were fixed or replied
  22. -H O W Basics Security Performance Errors Bigger Picture Requirements NIH Architecture Avoid mistakes that may be damaging Get things right Complex Simple Long term maintainability & productivity boosts
  23. _‫ף‬‫הסו‬