1. Code Review
and other aspects of project organization – a case study of SAOS
(www.saos.org.pl)
Łukasz Dumiszewski, ICM, University of Warsaw, XI.2014

2. Plan of the presentation
 Code Review – theory
 Code Review in SAOS
 Conclusions
Duration: about 1h
Helpful knowledge: git, GitHub (at least superficial)

3. Code Review - definition
From wikipedia:
Code review is systematic examination (sometimes
referred to as peer review) of computer source code. It is
intended to find mistakes overlooked in the initial
development phase, improving the overall quality of
software.

4. Code Review – pros
 Fewer errors
 Better code design
 Code standardization (tests, comments)
 Code clarity (division into sections, sensible variable names, short
methods)
 Code and meaning of every module known to everyone
 Improvement of programming skills
 Better team collaboration

5. Code Review – cons
 Longer time of functionality delivery (but maybe it only seems so)
 Negative emotions (arguments, creator’s ego hurt)
 Revising someone else’s code may be dull/ frustrating

6. Code Review – different approaches
 Formal code review
 Lightweight code review

7. Code Review – formal
Formal code review
Meetings, line-by-line code inspection by the whole team
Pros:
Better code: cleaner, fewer errors, sensibly designed
Cons:
Takes long time, possible negative emotions

8. Code Review – lightweight
Lightweight code review
over-the-shoulder/ e-mail/ tool-assisted/ pair-programming
Pros:
Better code: cleaner, fewer errors, sensibly designed and takes less
time than the formal method
Cons:
Some time still needed, negative emotions can also appear

9. Code Review – good practices
Smart Bear
http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf
http://smartbear.com/SmartBear/media/pdfs/WP-CC-11-Best-Practices-of-Peer-Code-
Review.pdf
1. Review fewer than 200-400 lines of code at a time
2. Aim for your inspection rate of less than 300-500 LOC/hour
3. Take enough time for a proper, slow review, but not more than 60-90 minutes.
4. Authors should annotate source code before the review begins.
5. Establish quantifiable goals for code review and capture metrics so you can improve your
processes.
6. Checklists substantially improve results for both authors and reviewers.
7. Verify that defects are actually fixed!
8. Managers must foster a good code review culture in which finding defects is viewed
positively.
9. Beware the “Big Brother” effect.
10. The Ego Effect: Do at least some code review, even if you don’t have time to review it all
11. Lightweight-style code reviews are efficient, practical, and effective at finding bugs.

10. Code Review in SAOS – what is SAOS?
SAOS is an online Polish Court Judgment Analysis System that
gathers judgment data from different indpendent court
applications, and allows for searching, browsing and analysing
the data through the web user interface or RESTful API.
See:
www.saos.org.pl
www.github.com/CeON/saos

11. Code Review in SAOS – motivation
 Pluses as mentioned before
 Wish to familiarize ourselves with CR practices
 Wish to see if it really works

12. Code Review in SAOS – technique
 Methodology: Scrum
 Approach: Lightweight / tool-assisted /
 Tool: GitHub pull requests

13. Scrum methodology – short definition
Iterative and incremental agile methodology of
managing product development.
In this methodology the development of a product is
divided into smaller consecutive iterations; lasting
max one month, called sprints.

14. The Scrum methodology in SAOS
 One week sprints
 Daily scrum meetings
 Summing up the previous day
 Plans for the next
 Weekly sprint meeting
 Summing up the sprint
 Choosing tasks for the next week
 Assigning CR partners to one another

15. The Scrum methodology in SAOS – details
 Tasks and sprints are GitHub’s issues and milestones
 Each task takes max 2 days
 While planning a sprint the time for the Code Review (20%) is
taken into account
 Code Review has the highest priority (so the colleague
doesn’t have to wait)
 Every task must pass the Code Review
The 4 lasts points are preconditions of successful CR

16. Lightweight CR in SAOS – core principles
 There is not ‘commit’ without CR
 Rotation of CR partners
 CR has the highest priority
 One CR for one task
 And… we take it seriously

17. Lightweight CR in SAOS in practice
1. Review fewer than 200-400 lines of code at a time
One CR for one task and each task is short (no more than 2 days)
2. Aim for your inspection rate of less than 300-500 LOC/hour
Depends on the programmer, generally met.
3. Take enough time for a proper, slow review, but not more than 60-90
minutes.
20% of time devoted to CR.
4. Authors should annotate source code before the review begins.
We don’t do it.
5. Establish quantifiable goals for code review and capture metrics so you can
improve your processes.
We don’t do it. Better tool needed.
6. Checklists substantially improve results for both authors and reviewers.
https://github.com/CeON/saos/wiki/Code-review#the-code-review-
common-checklist

18. Lightweight CR in SAOS – in practice cont.
7. Verify that defects are actually fixed!
Met. A task is not accepted until all remarks are closed.
8. Managers must foster a good code review culture in which finding defects is
viewed positively.
CR is just one of the tasks. Finding bugs is considered to be a positive
characteristic, every bug corrected is one step to closer to perfection. They who
make not mistakes make nothing 
9. Beware the “Big Brother” effect.
We know each other’s skills. This is a code review and not a code writer review.
10. The Ego Effect: Do at least some code review, even if you don’t have time to
review it all
More time devoted to code clarity, checking the test coverage.
11. Lightweight-style code reviews are efficient, practical, and effective at
finding bugs.
Some bugs avoided. More in the conclusion.

19. GitHub pull requests - definition
GitHub functionality that allows to compare and see the
code differences between two branches or repositories.
Main features:
 Preview of changes (all or a selected commit)
 Commenting on changes
 Statuses (closed, open)

20. GitHub pull requests - approaches
 Fork repository model
A programmer works on a cloned repo. They are not permitted to
make changes in the main repo – some designated people may do
this.
OK for large teams or open-source projects.
 Shared repository model
Everybody works directly on the main repo. New functionalities are
developed on separate branches.
OK for small teams.

21. GitHub pull requests – fork repository model
Repo
Repo
clone
Local
Repo
LOCAL
Pull Request
REMOTE
(gitHub)
Pull
Pull/ Push

22. GitHub pull requests – shared repo model
Description of this process: https://github.com/CeON/saos/wiki/Code-review
LOCAL
Pull Request
REMOTE
(gitHub)
Push
master feature
master feature
Repo
Repo
1
2
3
4
5
6

23. Code Review in SAOS - observations
 CR only makes sense if the team treats it as part of its
responsibilites (motivation, strict rules)
 CR takes time, about 20%, 1 day a week
 Minor problems with starting a new task can occur if the task is
related to another one just passed to CR
 To a high degree CR relies on a reviewer’s skills, their knowledge of
a given domain.
 Tasks have to be short (we decreased the max time for a task from
original 3 to 2 days, to make it shorter and thus easier to revise)

24. Code Review w SAOS – observations cont.
 No significant problems related to negative emotions occurred.
Some positive ones have: „I have learned something new”, „I didn’t
know you can do it this way” or „It’s good to know somebody will
take a look at this.”
 The pros listed at the beginning of the presentation proved to be
true. In particular: code standardization, observance of rules
(writing tests etc.), familiarity of each programmer with the whole
code.

25. Code Review in SAOS – observations cont.
 The time devoted to CR has not been wasted, it has paid off
(cleaner, faster & easier to extend and more reliable code;
programmers know the whole system)
 In the longer term CR has had very positive influence on the
team collaboration and programmers’ skills.