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.

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

8. -
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
.
.
.

9. -
1
Time
Take time to review
H O W

10. -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?

11. -H O W
3
Basics
Coding Standards
Indentation
Naming
Simple algorithm improvements
…
We’ll automate most of it once we know it

13. -H O W
4
Requirement
Does the code do what is in the
requirements?

14. -H O W
5
Bigger picture
Think about things the developer may not be
taking into consideration
Question the value

16. -H O W
6
NIH
Is the code reinventing the wheel?
Are there gems/solutions out there?
PFE™

17. -H O W
7
Errors
Both on logic and business

19. -H O W
8
Security
XSS
SQL Injection
Encryption
…

21. -H O W
9
Performance
SQL Overkill
DB Indexes
Slow processes not in background
…

23. -H O W
10
Architecture
Hardest part IMO, we’ll
focus on learning that later

25. -H O W
11
Teach
Not only point, try to be didactic
Share things that may not even
be related to the code itself

27. -H O W
12
Learn
About software, about the project,
about the people

28. -H O W
13
Be constructive
Code reviews are team work

30. -H O W
14
Review again
If you sent comments check that they were
fixed or replied

31. -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

32. _‫ף‬‫הסו‬