Code reviews provide many benefits like finding bugs, improving code quality, shared knowledge across teams, and decreased bus factor. An effective code review process involves great reviewers who objectively evaluate code and provide clear feedback, and great submitters who thoroughly test their code and are responsive to feedback. Growing a strong culture of code reviews depends on both reviewers and submitters following best practices.

1. How to successfully
grow a code review
culture

2. What will we learn today? - Part 1
Why do we code review?
What are the benefits?
Our Code Review Process
How to Grow a Culture

3. What will we learn today? - Part 2
How to be a Great Reviewer
How to a be a Great Submitter
Using Code Review to Build a Stronger Team

4. Why do we
code review?

5. Find Design Flaws & Bugs
So they can be identified and remedied before the code is complete
Case Studies on Review:
 Decrease bug rate by 80%
 Increase productivity by 15%

6. The goal is to find bugs
before
your customers or QAs do.

7. Shared Ownership
We’re all in this together
👀 results in positive motivation
Overall increase in code quality

8. Shared Knowledge
No developer is the only expert
Developers gain familiarity with different
modules via review
Decrease the “Bus Factor”

9. Factor?
concentrated specialized knowledge
will one person sabotage the project if they left?

10. Leave a Paper Trail
Code Reviews add a wealth of knowledge!
Why was a particular decision made?

11. Improved code quality

12. Correlation between code review process satisfaction and code
quality satisfaction

13. Code reviews as a time saver, not a time expense

14. Code reviews as a time saver, not a time expense

15. Code Review Benefits?
Shared Ownership
Shared Knowledge
Reduce Bus Factor
Leave a Paper Trail
Find Bugs
Improved code quality

16. My current organization
has a great review culture.
As a result, I’ve become a
better programmer

17. Part 2

18. How to be a
Great Reviewer

20. Be Objective
“this method is missing a java documentation”
Instead of
“you forgot to write a docstring”

21. Ask Questions Don’t GiveAnswers
“Would it make more sense if… ?”
“Did you think about… ? ”

22. Offer Suggestions
“it might be easier to”
“we tend to do it this way”

23. Avoid these terms
Simply
Easily
Just
Obviously
Well, actually…

24. …now, simply

25. Have Clear Feedback
Strongly support your opinions
Share How & Why
Link to supporting blogs, stackoverflow
examples, or documentation.

26. Not Clear Feedback

27. Give a compliment for good work && || Great Idea

28. Don’t be a Perfectionist
For big issues, don’t let perfect get in the way
of perfectly acceptable.
Prioritize what’s important to you.
Usually 90% there is good enough.
Pareto principle.

29. It’s OK to Nit-Pick
Syntax Issue
Spelling Errors
Poor Variable Names
Missing corner-cases.

30. It’s OK to Nit-Pick
Save the nit-picks for last, after any
pressing architecture, design, or other large
scale issues have been addressed

31. Do Reviews in 24-48 hours

32. Define Done
Let the submitter know if you approve, or if
they need to make changes.
Use consistent language
Follow up when the submitter says they fixed something.

33. What should you look
for?

34. Functionality
I. Does the code actually do what it was supposed to do?
II. Do the tests really test the code meets the agreed requirements?

35. Maintainability
I. Do the tests cover a good subset of cases?
II. Do they cover happy paths and exceptional cases?
III. Are there cases that haven’t been considered?
IV. Are the exception error messages understandable?
V. Are confusing sections of code either
I. documented,
II. commented,
III. covered by understandable tests?

36. Design part1
1. How does the new code fit with the overall architecture?
2. What design patterns are used in the new code?
3. Does the code follow:
1. SOLID principles,
2. Domain Driven Design
3. KISS principle
4. GRASP

37. Design part 2
1. Is the code in the right place?
2. Does this new code follow the current practices?
3. Does the new code introduce duplication?
4. Is the code over-engineered?
5. Does the team balance considerations of reusability with YAGNI?

38. Readability
I. Do the names* actually reflect the thing they represent?
II. Can I understand what the code does by reading it?
III. Can I understand what the tests do?

39. How to be a Great Reviewer?
 Have Empathy
 Watch your Language
 Have Clear Feedback
 Give Compliments
 Don’t be a Perfectionist
 Complete review in a hour
 Define Done
 Look to important things

40. Part 3

41. How to be a
Great Submitter

43. Don’t get rubber-stamped.

44. Don’t be too clever.
Readability Counts!

45. Don’t be too clever.
It needs no explanation.
Good code is like a good joke.

46. Stages of Review.
1.before submission
2.submitted
3. (optional) work in progress (30-50%)
4. almost done (90-100%)
5.review completed

47. step 1:
before submission

48. Provide Context (The Why).
1.Link to the underlying ticket/issue
2.Document why the change was needed
3.For larger PRs, provide a changelog
4.Point out any side-effects

49. YOU are the Primary Reviewer
1.Review your code with the same level
of detail you would give giving reviews
2. Anticipate problem areas

50. The Primary Reviewer
1.Make sure your code works, and is
thoroughly tested
2. Don’t rely on others to catch your
mistakes.

51. Before Submitting, Try a CheckList

52. small stuff
o Did you check for reusable code or utility
methods?
o Did I remove debugger statements?
o Are there clear commit messages?

53. big stuff
o Is my code secure?
o Will it scale?
o Read the Checklist Manifesto

54. step 2:
submitted

55. You’re starting a conversation
o Don’t get too attached to your code
before the review process
o Anticipate comments and feedback
o Acknowledge you will make mistakes

56. step 3 (Optional):
work in progress

57. Submit Work in Progress PRs
o Necessary for bigger features
o Open them your code is 30-50% done
o Don’t be afraid of showing incomplete,
incremental work
o This is the right time to get feedback on bigger
issues with the code

58. step 4:
almost done

59. When Code is Almost Done
o Feedback to expect:
o Nit Picks
o Variable Names
o Documentation & Comments
o Small Optimization

60. One Review per Issue
o Solved an unrelated problem? make a new PR
with a separate diff
o If you’re solving multiple problems, break
them up into multiple PRs for ease of review.
o You can branch off your feature branch to
keep the diff small

61. Prevent Reviewer Burnout
o Remember, reviews lose value when they’re
more than 500 lines of code.
o Keep reviews small and relevant.
o If submitting a big review is unavoidable, give
the reviewer extra time.

62. Check Code
with Automated Tools

63. step 5:
review complete

64. Be Responsive
o Reply to every comment
o Common Responses:
o Resolved
o Won’t Fix
o If you won’t fix, make sure you’ve come to a
mutual understanding with the reviewer

65. It’s still a Conversation
If there were comments, let your reviewer
know when you’ve pushed changes and
are ready to be re-reviewed

66. Don’t Bike-Shed
o bikeshed.com
o back & forth > 3 times? step away from the
keyboard.
o talk instead!
o record the conversation in the Review

67. Fight for what you believe, but
gracefully accept defeat.

68. Don’t take it personally.
It’s an opportunity for growth.

70. What did we learn?

71. reviews decrease WTFs/m

72. less WTFs -> happier devs!

73. Thanks for your attention
Майкл Уэлан

74. Resources
1. How to Successfully Grow a Code Review Culture
2. What to Look for in a Code Review
3. Code Review Best Practices
4. Best Practices for Code Review
5. 2018 State of Code Review report.
6. The Best Kept Secrets of Peer Code Review