Practices for more effective, efficient peer code review

1. CODE REVIEW
BEST PRACTICES
OREN DIGMI | FEB 2018

2. 2
Code review is a very important part
of the software development cycle.
We are using pull requests to review
code on branches before it reaches
dev.
Code review is one of the most
difficult and time consuming part of
the software development process.
What is Code Review?
1
2
3

3. “No problem can be solved from the same
level of consciousness that created it”
3
Albert Einstein

4. Why reviewing code?
4
● Saving time and money. by finding bugs in early stage.
● Sharing knowledge across the team, no single
developer in the critical path.
● Team cohesion. encourage developer to talk each
other and bring them closer to each other.
● Coding standard. helps to maintain consistent coding
style across the team.

5. INSTRUCTIONS
5

6. 6
Before submitting a pull request
COMPILE
The code is not broken, should successful
compile and build.
COVERAGE
All code in codebase should be tested, the
coverage should not decrease by merging your
code.
Tests
Your tests code should run successfully and
pass travis run.
READY
Your code should be ready for PR, DO NOT assign
reviewer to your PR if it’s not completely ready.
JIRA
Linked to the relevant JIRA item (PR
name should start with the JIRA number)

7. Pull request example
7

8. Reviewing pull requests is HARD
8

9. ● To make sure that the
code is correct and of high
quality.
● Review for core logic and
architecture aspects.
● Review for adequate test
coverage.
The reviewer responsible for
the code reviewed by him!
Reviewer
responsibility
9

10. Code Review Guidelines
10

11. Preparing your code for review
11

12. Communicate with your reviewer
Give your reviewers background about your task.
Create Pull Request with a reasonable timeframes. Take into consideration the reviewer status, time for
reviewer to understand the code and goals, bugs and code refactoring.
Give your reviewers context on your change. Ideally, you should speak with them before any non-trivial
review or document the changes you’re making inside of the review’s description.
Make sure to summarize the change you’re making, why you are making those changes, and link to a
ticket or spec to provide any additional context.
Since most of us pull request authors have likely been reviewers already, simply put yourself in the shoes
of the reviewer and ask, “How could this be easier for me?”
12
Guidelines / Preparing your code review

13. Make smaller pull requests
Making smaller pull requests is the best way to speed up your review time. Keep your pull requests small
so that you can iterate more quickly and accurately. In general, smaller code changes are also easier to
test and verify as stable. When pull request is small, it’s easier for the reviewers to understand the
context and reason with the logic.
According to review study (see figure) the optimal effectiveness, developers should review fewer than
200-400 lines of code (LOC) at a time. Beyond that, the ability to find defects diminishes.
Reviewing 200-400 lines of code over 60-90 minutes, should yield 70-90% defect discovery.
Reading beyond 400 lines of code, the ability to find defects diminishes.
13
Guidelines / Preparing your code review

14. Make smaller pull requests
14
Guidelines / Preparing your code review
defect density dramatically decreases when the number of lines of inspection goes above 200, and it is almost zero after 400

15. Make your code easy to review- useful description
Writing a useful description for your pull request can almost be as effective as making a smaller pull
request. Make sure to provide helpful descriptions. The most helpful descriptions guide the reviewer
through the code as much as possible, highlighting related files and grouping them into concepts or
problems that are being solved. This saves the reviewer a lot of time because they don’t have to read
every file to try and group them up and identify related concepts.
15
Guidelines / Preparing your code review

16. Make your code easy to review- comments
Code should contain both high-level and in-line comments. High-level comments explain how all the
components fit together and how it handles any exceptional cases while in-line comments describe why
the code takes its current shape. This will make your code easier to understand for maintainers and
reviewers.
16
Guidelines / Preparing your code review

17. Read and annotate your code before you sent it to review
Before submitting for review, you should review your own diff for errors. Try to do this through the eyes of
someone who has never seen the code before. Look for any decisions that may cause confusion and may need
preemptive explanation. If you feel the code is too confusing, you may want to further refine your code before
sending it out for review. Catching these issues early will save both you and the reviewers time.
You should also annotate code before the review occurs because annotations guide the reviewer through the
changes, showing which files to look at first and defending the reason behind each code modification.
Annotations should be directed at other reviewers to ease the process and provide more depth in context. As an
added benefit, the author will often find additional errors before the review even begins. More bugs found prior to
review will yield in lower defect density because fewer bugs exist overall.
Another very important issue which is often under-rated is naming. Are packages, classes, methods and variables
in your view, optimally named? do you understand all the names?
17
Guidelines / Preparing your code review

18. Use this Checklist
● Am I having difficulty in understanding this code?
● Is there any complexity in the code which could be reduced by refactoring?
● Is the code well organized in a package structure which makes sense?
● Are the class names intuitive and is it obvious what they do?
● Are there any classes which are notably large?
● Are there any particularly long methods?
● Do all the method names seem clear and intuitive?
● Is the code well documented?
● Is the code well tested?
● Are there ways in which this code could be made more efficient?
● Style check your code.
18
Guidelines / Preparing your code review

19. During a code review
19

20. Avoid changes during the code review
Major changes in the middle of code review basically resets the entire review process. If you need to
make major changes after submitting a review, you may want to ship your existing review and follow-up
with additional changes. If you need to make major changes after starting the code review process, make
sure to communicate this to the reviewer as early in the process as possible.
20
Guidelines / During a code review

21. Respond to all actionable code review feedback
You should understand every piece of feedback from your reviewer and respond to each actionable
piece. Even if you don’t implement their feedback, respond to it and explain your reasoning. If there’s
something you don’t understand, ask questions inside or outside the code review.
21
Guidelines / During a code review

22. Code reviews are discussions, not dictation
You can think of most code review feedback as a suggestion more than an order. It’s fine to disagree with
a reviewer’s feedback but you need to explain why and give them an opportunity to respond.
22
Guidelines / During a code review

23. When doing a code review
23

24. Understand the code and requirements
Reviewer should:
● Be aware to the task description and requirements.
● Make sure you completely understand the code.
● Evaluate all the architecture tradeoffs.
24
Guidelines / When doing a code review

25. Check code on many aspects
1. Verify the code correctness.
* The code is bug-free .
* The code does what it was intended to do.
* Leak memory, etc.
2. Check code quality .
* Make sure the code is maintainable.
* Check the code is general as it need to be and well organized.
* Is there a better way to accomplish the goal?
* Style issues- not consistent with the rest of the codebase.
3. Verify the code is well tested.
* All code in codebase should be tested.
* Tests are written according Gett guidelines Writing Golang tests
* Make sure unit tests are isolated, don’t have unnecessary dependencies and testing the right things.
* Confirm adequate test coverage.
4. Make sure the code is safe to deploy.
* Ask if the code is forwards/backwards compatible.
* Run through a roll-back scenario to check for rollback safety.
* Dependencies with other services? 25
Guidelines / When doing a code review

26. Avoid many comments and use github review
When you have several comments you should use the review option in github, instead of comment each of them
separately, and notify the developer (PR owner) when you finished.
This will prevent confusion and providing clearly stated when the review ends.
26
Guidelines / When doing a code review

27. Comments level
Another best practice is divide your comments for 3 categories:
1. Critical:
Comments that the developer must to accept and change the code:
Examples: bug, wrong logic, memory leak etc.
2. Optional:
Recommends for the developer for changes, nice to have but not mandatory.
3. Positive Comment:
When you find nice piece of code, let the developer know your appreciation
27
Guidelines / When doing a code review

28. THANK YOU
28