Your SlideShare is downloading. ×
0
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Code reviews
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Code reviews

2,594

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? …

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
16 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,594
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
43
Comments
1
Likes
16
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 
 Question
 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. _‫ף‬‫הסו‬

×