The document discusses the importance and benefits of code reviews in software development, highlighting that one hour of code review can save about 100 hours of related work. It outlines best practices for conducting code reviews, including what to review, how to provide feedback, and selecting appropriate reviewers. The overarching goal is to improve code quality while fostering a culture of knowledge sharing and continuous improvement among developers.

1. Code Reviews Inside Out
Zagreb, 21 November 2019
Ines Jelovac Mandarić
Photo by Agence Olloweb on Unsplash

2. Code review

3. Benefits
quality assurance
knowledge sharing
time saving & money saving

4. Benefits
1 hour
of code review prevents
~100 hours
of related work
Document Inspection as an Agent of Change, Holland, 1999

5. Benefits
Handbook of Walkthroughs, Inspections and Technical Reviews, Freedman and Weinberg, 1990

6. Benefits
Software Defect-Removal Efficiency, Jones, 1996

7. Why it works?
1. Psychology:
blind spots
2. Detecting different
kind of problems
Photo by Charles 🇵🇭 on Unsplash

8. Problems
time consuming
&
money wasting
Photo by Jp Valery on Unsplash

9. History
Photo by Federica Galli on Unsplash

10. Today
Photo by Jesus Kiteque on Unsplash

11. What to review?
● Design
● Functionality
● Complexity
● Tests
● Naming
What to look for in a code review, Google, 2019 Photo by Steven Wright on Unsplash

12. What to review?
● Comments
● Style
● Documentation
● Check every line
● Context
What to look for in a code review, Google, 2019 Photo by Steven Wright on Unsplash

13. How to review code?
intuition
&
experience

14. What is the goal?
Photo by Fab Lentz on Unsplash

15. How to give feedback?
● Writing comments
○ Change request
○ Informational comment
● Talking

16. When to review?
One
bussiness day
Speed of Code Reviews, Google, 2019 Photo by Nathan Dumlao on Unsplash

17. How NOT to review code?
● Looking for typos
● Checking format
● Detecting dead code

18. How NOT to review code?
● Checking if it compiles
● Checking if it runs
● Checking if tests run

19. How NOT to review code?
● Focusing on bugs 🐛
● Discussing alternatives

20. How to prepare code for review?
● Submitting small amount of changes
● Self-review first
● Not relying on reviewer too much
● Writing good description

21. How to choose a reviewer?
● expert in technology used
● expert in domain

22. Who should review your code?
senior ➔ junior
junior ➔ senior
peer ➔ peer

23. Photo by Icons8 Team on Unsplash
Who should
NOT review
code?
managers

24. How many people should review code?
max 3
The Jet Propulsion Laboratory’s Experience with Formal Inspections, Bush and Kelly, 1989.
An Experiment to Assess Different Defect Detection Methods for Software Requirements Inspections, Porter and
Votta, 1994.

25. Recap
Reviewers
● Focus on quality
● Remember to talk
● Respond quickly
Authors
● Prepare code
before review
● Choose reviewer(s)
wisely and not too
many

26. Human factor
Photo by Sebastian Herrmann on Unsplash

27. For reviewers
● Short and clear
comments
● Stay objective
● Don't criticize
● Focus on problems, not
solutions
● Modify feedback
● Positive feedback
Photo by Ben White on Unsplash

28. For authors
● Understand comment
● Ask for extra info
● Appreciate feedback
● Learn and improve!
Photo by Ben White on Unsplash

29. General approach
● Show respect
● Don't take it personally
● Don't make it personal
● Identify problems in processes/organization
● Code review is not performance review!

30. Variations

31. Work in progress
● Incomplete work
● Early feedback
● Discuss alternatives
Photo by Josue Isai Ramos Figueroa on Unsplash

32. Pair programming
● Type of in-person review
● Live session
Photo by Brooke Cagle on Unsplash

33. Summary
● Improve code quality
● Automate what possible
● Give good feedback
● Professional peer to peer approach
● Learn from mistakes

34. Image from http://thedataist.com/ten-good-coding-practices-for-data-scientists/
Conclusion

35. Resources
● Code Complete, Steve McConnell, 2004
● Design and Code Inspections to Reduce
Errors in Program Development by Michael
Fagan, 1976
● Code Review Developer Guide, Google, 2019