Code reviews can be done in very different processes. In this talk we discuss our lightweight process for informal reviews with structured results. It's the first talk in our Code Review Culture Series.

1. Code Reviews
@ Quatico
Jan Wloka
Quatico Solutions AG

2. Code Reviews, again?

3. Why do we review code?
• Find bugs
• Transfer knowledge
• Lower project cost
• [ Hiring a candidate ]

4. How would you review?
• Branch —> Code —> Assign Pull Request!
• Create a feature branch
• Implement the feature
• Create a pull request
• Assign a reviewer
• Discuss (and add changes to)
pull request
• Approve and merge pull request

5. PR, really? You also
could…
• Code —> Push —> Assign Ticket!
• Implement the feature
• Commit with message
• Push changes
• Assign ticket w/ commits
to review

6. Sure, but how do I review?
• Read the issue ticket: “the why”
• Checkout the code/branch
• Run the tests w/ coverage
• Check the console
• Review the change

7. What should I be reviewing?
•Change
• Complexity: Shape of change = complex
• Test Coverage
•Code
• Naming, Functionality, Control Structures, Error Handling
• Tricky things (Thread Safety, Resource Leaks, Timezones)
• No obvious things: Performance, Security
•Design
• Single Responsibility Principle (Implicit dependencies)
• Data lifecycle (Cache invalidation, Reentrancy)
•Everything else: Tests, Builds, Deployment scripts, Configurations

8. Whoa. We should make
checklist!

9. So, what’s hard about it?
• Process is more difficult than the result
• Discuss your code with your peers
• How to disagree?
• Don’t just agree on the issue —> Silent Commitment.
• No fear of conflict —> Be curious!
• Agree to disagree —> Ask and learn.
• Form a strong code review culture!

10. Okay, but what
can I do?

11. Authors: Provide Context!
• What problems are we solving?
• Pull Request / Commit message:
• Add 2 paragraphs of context.
• Annotate source code.
• Describe changes, defending reasons and
methods.
• Re-think and explain every change.

12. Background: Prepare
your code.
SmartBear Study
300 reviews,
about 15%
random samples

13. Guidelines for Authors
• The primary reviewer is the
author, i.e. YOU.
• Review your own code
BEFORE commit.
• Create a checklist for
yourself.
• You are not your code.
Good code is…

14. Reviewers: Ask don’t tell
• What have you learned?
• Critique the code, instead of people
• Ask questions, rather than make statements
• “What do you think …”
• “Did you consider …”
• “Can you clarify …”
• Avoid ‘why’ questions, be more specific!
• Don’t forget to praise.

15. Background: How many
LOCs to review?
Defect density
dramatically decreases
when the number of
lines of inspection
goes above 200, and
is almost zero after 400.

16. Background:
Inspection rate
If you don’t spend
enough time, you
won't
find many defects.
Faster than
400-500 LOC/hour
results in severe
drop-off
in effectiveness.

17. Guidelines for Reviewers
• Review fewer than 400
LOC at a time.
• Aim for less than 500
LOC / hour.
• Take your time, but quit
after 60mins.
• Establish quantifiable
goals. Capture metrics.

18. Goal: Structured
feedback
• Must Haves: “How to get your approval”
• Customer facing incompleteness and inconsistencies
• Obvious bugs, and everything on the checklist
• Nice To Haves: “How to improve the code base”
• New design flaws, or known code smells
• Reduced test coverage, performance
• Everything you can live with, but don’t want to
• Superhero Deeds: “How to show love to your team”
• What are your peers working on? Can you help?
• Extra test data, mocks, anything done easily that helps.

19. We all make mistakes, but…
• Verify that defects are actually
fixed!
• Managers foster good code
reviews.
• ‘Big Brother Effect’ versus
‘Ego Effect’.
• Authors never merge own Pull
Requests.
• Tech leads aren’t gatekeepers.

20. Next Steps
• Authors: “Provide more context”
• Favour pull requests, over direct commits.
• Annotate your change, explain the ‘why’
• Maintain a personal checklist.
• Review every modification, before push.
• Reviewers: “Provide structured feedback”
• Critique the code, not the coder.
• Use the checklist.
• Be specific, and helpful.
• Don’t forget to praise.

21. Goal: Strong Review
Culture
• Better code.
• Better developers.
• Team ownership > Code ownership.
• Healthy debate > No silent agreement.

22. Thank You.
jan.wloka@quatico.com
@crashtester

23. References
• Best Practices for Code Reviews
http://www.smartbear.com/docs/
BestPracticesForPeerCodeReview.pdf
• The Ten Commandments of
Egoless Programming
http://www.codinghorror.com/blog/2006/05/the-
ten-commandments-of-egoless-programming.html
• Effective Code Reviews Without
the Pain
http://www.developer.com/java/other/article.php/
3579756
Thanks to geek-and-poke.com & commadot.com