Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
How to successfully
grow a code review
culture
@nnja
Nina Zakharenko
What will we learn today? - Part 1
Why do we code review?
What are the benefits?
Our Code Review Process
How to Grow a Cul...
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 S...
Not one size fits all!
team size
2 vs 10
product type
agency vs in-house
defect tolerance
jet engines vs mobile games
Why Code Review?
?
Code Reviews Can
Be Frustrating
Apparent
Code Review Frustrations
Adds time demand
Adds process
Can bring up team tensions
“smart” devs think they don’t n...
How do you get people to
change the way they work?
Show them the Benefits are
Crystal Clear
Find Design Flaws
& Bugs
So they can be identified and remedied before
the code is complete
Case Studies on Review:
➡ bug ...
The goal is to find bugs
before your customers do.
Shared Ownership
We’re all in this together
👀 results in positive motivation
Overall increase in code quality
Shared Knowledge
No developer is the only expert
Developers gain familiarity with
different modules via review
Decrease th...
🚍 Factor?
concentrated specialized
knowledge
will one person sabotage the
project if they left?
Leave a Paper Trail
Code Reviews add a wealth of
knowledge!
Why was a particular decision
made?
Find Bugs
Shared Ownership
Shared Knowledge
Reduce Bus Factor
Leave a Paper Trail
Code Review Benefits?
My current organization has a great
review culture.
As a result, I’ve become a better
programmer.
What’s Our Process?
Tools
We use GitHub enterprise
Many other tools exist
GitHub added Review tools September
2016!
Formal Reviews
Inline Comments
Blocked Merging
Workflow
make
feature
branch
do work
open
pull
request
Workflow
assign
reviewer
complete
review
merge
branch
upstream
Feature Branches?
Feature branches are merged into a
development branch, not master.
We can QA in a staging
environment th...
Grow a Culture
It starts with a
Commitment
Make a commitment to always Review before
Merge
Present the Facts
Don’t force it
New ideas tak...
Code Reviews need to
be Universal
Doesn’t matter how Senior / Junior you are
Only Senior Devs reviewing == bottleneck
Ineq...
Code Review is done by your
peers,
not management.
Consistent Code
Your code isn’t yours, it belongs to your
Company
Code should fit your company’s expectations
and style, n...
Style Guide
Distinguishes personal taste from
functionality
Should be agreed upon before hand
Great codebases are written ...
Consistent Code is Easier to
Maintain by a Team
No Blame Culture
Failure is inevitable
Mistakes become team, not
individual responsibility
Needs management support
Blameless Post Mortems
Meet shortly after Incident Resolved
Understand the root cause
Document how it was fixed
Identify h...
For a blameless culture,
don’t point fingers!
“
When code reviews are part of the
culture, people don’t expect their
changes to be reviewed, they want
their changes to ...
Make a Commitment
Universal Code Review
Performed by Peers
Style Guide = Consistency
How to Grow Culture?
Starts with No Blame
Culture
How to Grow Culture?
How should we code
review?
?
How to be a
Great Reviewer
Have Empathy
Why do you think
you’re so hostile
in code reviews?
If only I had been
more popular in
High School.
Be Objective
“this method is missing a docstring”
instead of
“you forgot to write a docstring”
Ask Questions
Don’t Give Answers
“Would it make more sense if… ?”
“Did you think about… ? ”
Offer Suggestions
“it might be easier to”
“we tend to do it this way”
Avoid these terms
Simply
Easily
Just
Obviously
Well, actually…
… now, simply
Have Clear Feedback
Strongly support your opinions
Share How & Why
Link to supporting blogs, stackoverflow
examples, or do...
Not clear feedback
Compliment Good Work & Great Ideas
Don’t be a perfectionist
Don’t be a Perfectionist
For big issues, don’t let perfect get in the way
of perfectly acceptable.
Prioritize what’s impor...
It’s OK to Nit-Pick
Syntax Issues
Spelling Errors
Poor Variable Names
Missing corner-cases
It’s OK to Nit-Pick
Save the nit-picks for last, after any
pressing architecture, design, or other large
scale issues have...
Avoid Burn-Out
Studies show reviewer should look at 200-400
lines of code at a time for maximum impact
https://smartbear.c...
https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
Limit Reviews to 200-400 lines between 60 and...
Do Reviews in 24-48 hours
Define Done
Let the submitter know if you approve, or if
they need to make changes.
Use consistent language
LGTM or Change...
Have Empathy
Watch your Language
Have Clear Feedback
Give Compliments
Don’t be a Perfectionist
How to be a Great Reviewer?
Avoid Burn Out
Complete in 24-48 hours
Define Done
How to be a Great Reviewer?
How to Be a
Great Submitter
Submitter Reviewer
Don’t get rubber-stamped.
Don’t be too clever.
Readability Counts!
“
Good code is like a good joke.
It needs no explanation.
Russ Olsen
Stages of Review
0 before submission
1 submitted
2 (optional) work in progress (30-50%)
3 almost done (90-100%)
4 review c...
step 0:
before submission
Provide Context (The Why)
Link to the underlying ticket/issue
Document why the change was needed
For larger PRs, provide a...
YOU are the
Primary Reviewer
Review your code with the same
level of detail you would give giving
reviews.
Anticipate prob...
The Primary Reviewer
Make sure your code works, and is
thoroughly tested.
Don’t rely on others to catch your
mistakes.
Before Submitting,
Try a CheckList
☑︎ small stuff
Did you check for reusable code or utility
methods?
Did I remove debugger statements?
Are there clear commi...
☑︎ big stuff
Is my code secure?
Will it scale?
Read the Checklist Manifesto
step 1:
submitted
You’re starting a
conversation.
Don’t get too attached to your code
before the review process
Anticipate comments and feed...
step 2:
(optional)
work in progress
Submit Work in Progress PRs
Necessary for bigger features
Open them your code is 30-50% done
Don’t be afraid of showing in...
When Code is Work in Progress
Feedback to expect:
Architectural Issues
Problems with Overall Design
Design Pattern Suggest...
step 3:
almost done
When Code is Almost Done
Feedback to expect:
Nit Picks
Variable Names
Documentation & Comments
Small Optimizations
One Review per Issue
Solved an unrelated problem? make a new PR
with a separate diff
If you’re solving multiple problems, ...
Prevent Reviewer Burnout
Remember, reviews lose value when they’re
more than 500 lines of code.
Keep reviews small and rel...
✔ Check Code
with Automated Tools
✔ Linter
check syntax or style guide violations
✔ Tests
Write tests!
Don’t know code health if tests are failing
Tests Identify problems immediately
✔ Continuous
Integration
automated build with every push
✔ Coverage
% of code execute when running a test suite
✔ Coverage
Coverage tools can integrate into GitHub.
coverage.py
coveralls.io
step 4:
review complete
Be Responsive
Reply to every comment
Common Responses:
Resolved
Won’t Fix
If you won’t fix, make sure you’ve come to a
mut...
If there were comments, let your reviewer
know when you’ve pushed changes and
are ready to be re-reviewed.
It’s still a Co...
Don’t Bike-Shed
bikeshed.com
back & forth > 3 times? step away from the
keyboard.
talk instead!
record the conversation in...
Fight for what you believe, but
gracefully accept defeat.
Don’t take it personally.
It’s an opportunity for growth.
Provide the Why
Review your own code
Expect Conversation
Submit in progress work
How to be a Great Submitter?
How to be a Great Submitter?
Use automated tools
Be Responsive
Accept Defeat
Code
Reviews
Build
A Stronger
Team
Use that as an advantage
when someone new joins!
On your first day…
Newbies
Not everyone has experience being reviewed.
Remember what it felt like when you
introduced the process.
Ease into ...
On-boarding
Start by reading recently completed reviews.
The first submitted review is always the
hardest
First review sho...
Everyone’s a Reviewer
Junior devs start by doing pair-reviews with a
more experienced teammate.
Use it as a mentorship opp...
“
Hiring senior engineers is hard. You
can hire junior engineers, and grow
them into functional productive parts
of your t...
If you’re not doing code reviews,
you’re missing a big
opportunity.
Remember…
Allocate the time
Develop, don’t force the culture
Not one size fits all
Or a one stop fix
Use in addition to te...
What did we learn?
?
reviews decrease WTFs/m
the only valid measurement
of code quality
less WTFs ➡
happier devs!
bonus reading & resources at
the end of the slides
bit.ly/reviewcode
Bonus Material!
@nnja
bit.ly/reviewcode
nina.writes.code@gmail.com
Thanks!
Resources & Additional Reading
Microsoft Study on Effective Code Review

https://www.microsoft.com/en-us/research/wp-conten...
Resources & Additional Reading
Rebecca's Rules for Constructive Code Review

https://storify.com/ReBeccaOrg/rebecca-s-rule...
Example Style Guides
Python
https://www.python.org/dev/peps/pep-0008/

Scala
https://github.com/paypal/scala-style-guide

...
Credits
Special thanks to all the people who made and
released these awesome resources for free:
Presentation template by ...
How to successfully grow a code review culture
Upcoming SlideShare
Loading in …5
×

How to successfully grow a code review culture

7,593 views

Published on

As a team grows, code ownership is distributed. Code review becomes increasingly important to support the maintainability of complex codebases. An effective code base is on that can be worked on collaboratively by a team.

In this talk we'll discuss how to introduce a successful code review culture to your development team that will foster the idea of shared ownership. This in turn will result in a happy and healthy code base.

https://webexpo.net/prague2016/talk/how-to-successfully-grow-a-code-review-culture/

Published in: Software
  • Like to know how to take easy surveys and get huge checks - then you need to visit us now! Having so many paid surveys available to you all the time let you live the kind of life you want. learn more...◆◆◆ https://tinyurl.com/realmoneystreams2019
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Like to know how to take easy surveys and get huge checks - then you need to visit us now! Having so many paid surveys available to you all the time let you live the kind of life you want. learn more...▲▲▲ http://ishbv.com/surveys6/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • how to lose weight in a week without exercising or dieting ■■■ https://tinyurl.com/y6qaaou7
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Increase Penis Size - Secrets to Increase Penis Size Revealed. ★★★ https://tinyurl.com/getpebible2019
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • The methods and techniques in the PE Bible are exclusive to this unique program. The two step system involves low cost off the shelf natural supplements and a specially designed exercise program. Many users experience gains of almost an inch within just a few weeks of starting this unique program! Imagine having 2-4 inches of extra length and girth added onto your penis size, this Penis Enlargement Bible makes it possible. Over 5000 copies of this product have already been sold, and unlike most products on the market there is real video proof from actual users that show REAL results. You can see the video here ➤➤ http://ishbv.com/pebible/pdf
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

How to successfully grow a code review culture

  1. 1. How to successfully grow a code review culture @nnja Nina Zakharenko
  2. 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. 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. 4. Not one size fits all! team size 2 vs 10 product type agency vs in-house defect tolerance jet engines vs mobile games
  5. 5. Why Code Review? ?
  6. 6. Code Reviews Can Be Frustrating
  7. 7. Apparent Code Review Frustrations Adds time demand Adds process Can bring up team tensions “smart” devs think they don’t need it
  8. 8. How do you get people to change the way they work?
  9. 9. Show them the Benefits are Crystal Clear
  10. 10. Find Design Flaws & Bugs So they can be identified and remedied before the code is complete Case Studies on Review: ➡ bug rate by 80% productivity by 15% https://blog.codinghorror.com/code-reviews-just-do-it/
  11. 11. The goal is to find bugs before your customers do.
  12. 12. Shared Ownership We’re all in this together 👀 results in positive motivation Overall increase in code quality
  13. 13. Shared Knowledge No developer is the only expert Developers gain familiarity with different modules via review Decrease the “Bus Factor”
  14. 14. 🚍 Factor? concentrated specialized knowledge will one person sabotage the project if they left?
  15. 15. Leave a Paper Trail Code Reviews add a wealth of knowledge! Why was a particular decision made?
  16. 16. Find Bugs Shared Ownership Shared Knowledge Reduce Bus Factor Leave a Paper Trail Code Review Benefits?
  17. 17. My current organization has a great review culture. As a result, I’ve become a better programmer.
  18. 18. What’s Our Process?
  19. 19. Tools We use GitHub enterprise Many other tools exist GitHub added Review tools September 2016!
  20. 20. Formal Reviews
  21. 21. Inline Comments
  22. 22. Blocked Merging
  23. 23. Workflow make feature branch do work open pull request
  24. 24. Workflow assign reviewer complete review merge branch upstream
  25. 25. Feature Branches? Feature branches are merged into a development branch, not master. We can QA in a staging environment that mimics production When necessary, we can hotfix master
  26. 26. Grow a Culture
  27. 27. It starts with a Commitment Make a commitment to always Review before Merge Present the Facts Don’t force it New ideas take time to root
  28. 28. Code Reviews need to be Universal Doesn’t matter how Senior / Junior you are Only Senior Devs reviewing == bottleneck Inequality breeds dissatisfaction Break down old barriers and status quos
  29. 29. Code Review is done by your peers, not management.
  30. 30. Consistent Code Your code isn’t yours, it belongs to your Company Code should fit your company’s expectations and style, not your own. Reviews should encourage consistency for code longevity
  31. 31. Style Guide Distinguishes personal taste from functionality Should be agreed upon before hand Great codebases are written by a team, but look like they were written by an individual
  32. 32. Consistent Code is Easier to Maintain by a Team
  33. 33. No Blame Culture Failure is inevitable Mistakes become team, not individual responsibility Needs management support
  34. 34. Blameless Post Mortems Meet shortly after Incident Resolved Understand the root cause Document how it was fixed Identify how to prevent it in future
  35. 35. For a blameless culture, don’t point fingers!
  36. 36. “ When code reviews are part of the culture, people don’t expect their changes to be reviewed, they want their changes to be reviewed. https://www.caktusgroup.com/blog/2014/07/28/culture-code-reviews/
  37. 37. Make a Commitment Universal Code Review Performed by Peers Style Guide = Consistency How to Grow Culture?
  38. 38. Starts with No Blame Culture How to Grow Culture?
  39. 39. How should we code review? ?
  40. 40. How to be a Great Reviewer
  41. 41. Have Empathy Why do you think you’re so hostile in code reviews? If only I had been more popular in High School.
  42. 42. Be Objective “this method is missing a docstring” instead of “you forgot to write a docstring”
  43. 43. Ask Questions Don’t Give Answers “Would it make more sense if… ?” “Did you think about… ? ”
  44. 44. Offer Suggestions “it might be easier to” “we tend to do it this way”
  45. 45. Avoid these terms Simply Easily Just Obviously Well, actually…
  46. 46. … now, simply
  47. 47. Have Clear Feedback Strongly support your opinions Share How & Why Link to supporting blogs, stackoverflow examples, or documentation.
  48. 48. Not clear feedback
  49. 49. Compliment Good Work & Great Ideas
  50. 50. Don’t be a perfectionist
  51. 51. 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.
  52. 52. It’s OK to Nit-Pick Syntax Issues Spelling Errors Poor Variable Names Missing corner-cases
  53. 53. 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.
  54. 54. Avoid Burn-Out Studies show reviewer should look at 200-400 lines of code at a time for maximum impact https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
  55. 55. https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/ Limit Reviews to 200-400 lines between 60 and 90 minutes, then take a break. Avoid Burn-Out
  56. 56. Do Reviews in 24-48 hours
  57. 57. Define Done Let the submitter know if you approve, or if they need to make changes. Use consistent language LGTM or Changes Requested Follow up when the submitter says they fixed something
  58. 58. Have Empathy Watch your Language Have Clear Feedback Give Compliments Don’t be a Perfectionist How to be a Great Reviewer?
  59. 59. Avoid Burn Out Complete in 24-48 hours Define Done How to be a Great Reviewer?
  60. 60. How to Be a Great Submitter
  61. 61. Submitter Reviewer
  62. 62. Don’t get rubber-stamped.
  63. 63. Don’t be too clever. Readability Counts!
  64. 64. “ Good code is like a good joke. It needs no explanation. Russ Olsen
  65. 65. Stages of Review 0 before submission 1 submitted 2 (optional) work in progress (30-50%) 3 almost done (90-100%) 4 review completed
  66. 66. step 0: before submission
  67. 67. Provide Context (The Why) Link to the underlying ticket/issue Document why the change was needed For larger PRs, provide a changelog Point out any side-effects
  68. 68. YOU are the Primary Reviewer Review your code with the same level of detail you would give giving reviews. Anticipate problem areas
  69. 69. The Primary Reviewer Make sure your code works, and is thoroughly tested. Don’t rely on others to catch your mistakes.
  70. 70. Before Submitting, Try a CheckList
  71. 71. ☑︎ small stuff Did you check for reusable code or utility methods? Did I remove debugger statements? Are there clear commit messages?
  72. 72. ☑︎ big stuff Is my code secure? Will it scale? Read the Checklist Manifesto
  73. 73. step 1: submitted
  74. 74. You’re starting a conversation. Don’t get too attached to your code before the review process Anticipate comments and feedback Acknowledge you will make mistakes
  75. 75. step 2: (optional) work in progress
  76. 76. Submit Work in Progress PRs Necessary for bigger features Open them your code is 30-50% done Don’t be afraid of showing incomplete, incremental work This is the right time to get feedback on bigger issues with the code
  77. 77. When Code is Work in Progress Feedback to expect: Architectural Issues Problems with Overall Design Design Pattern Suggestions
  78. 78. step 3: almost done
  79. 79. When Code is Almost Done Feedback to expect: Nit Picks Variable Names Documentation & Comments Small Optimizations
  80. 80. One Review per Issue Solved an unrelated problem? make a new PR with a separate diff If you’re solving multiple problems, break them up into multiple PRs for ease of review. You can branch off your feature branch to keep the diff small
  81. 81. Prevent Reviewer Burnout Remember, reviews lose value when they’re more than 500 lines of code. Keep reviews small and relevant. If submitting a big review is unavoidable, give the reviewer extra time. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/bosu2015useful.pdf
  82. 82. ✔ Check Code with Automated Tools
  83. 83. ✔ Linter check syntax or style guide violations
  84. 84. ✔ Tests Write tests! Don’t know code health if tests are failing Tests Identify problems immediately
  85. 85. ✔ Continuous Integration automated build with every push
  86. 86. ✔ Coverage % of code execute when running a test suite
  87. 87. ✔ Coverage Coverage tools can integrate into GitHub. coverage.py coveralls.io
  88. 88. step 4: review complete
  89. 89. Be Responsive Reply to every comment Common Responses: Resolved Won’t Fix If you won’t fix, make sure you’ve come to a mutual understanding with the reviewer
  90. 90. If there were comments, let your reviewer know when you’ve pushed changes and are ready to be re-reviewed. It’s still a Conversation
  91. 91. Don’t Bike-Shed bikeshed.com back & forth > 3 times? step away from the keyboard. talk instead! record the conversation in the Review
  92. 92. Fight for what you believe, but gracefully accept defeat.
  93. 93. Don’t take it personally. It’s an opportunity for growth.
  94. 94. Provide the Why Review your own code Expect Conversation Submit in progress work How to be a Great Submitter?
  95. 95. How to be a Great Submitter? Use automated tools Be Responsive Accept Defeat
  96. 96. Code Reviews Build A Stronger Team
  97. 97. Use that as an advantage when someone new joins!
  98. 98. On your first day…
  99. 99. Newbies Not everyone has experience being reviewed. Remember what it felt like when you introduced the process. Ease into it!
  100. 100. On-boarding Start by reading recently completed reviews. The first submitted review is always the hardest First review should be small. Share the style guide
  101. 101. Everyone’s a Reviewer Junior devs start by doing pair-reviews with a more experienced teammate. Use it as a mentorship opportunity. “When your team succeeds, you succeed.”
  102. 102. “ Hiring senior engineers is hard. You can hire junior engineers, and grow them into functional productive parts of your team. Sasha Laundy http://blog.sashalaundy.com/talks/asking-helping/
  103. 103. If you’re not doing code reviews, you’re missing a big opportunity.
  104. 104. Remember… Allocate the time Develop, don’t force the culture Not one size fits all Or a one stop fix Use in addition to tests, QA, etc for maximum impact
  105. 105. What did we learn? ?
  106. 106. reviews decrease WTFs/m the only valid measurement of code quality
  107. 107. less WTFs ➡ happier devs!
  108. 108. bonus reading & resources at the end of the slides bit.ly/reviewcode Bonus Material!
  109. 109. @nnja bit.ly/reviewcode nina.writes.code@gmail.com Thanks!
  110. 110. Resources & Additional Reading Microsoft Study on Effective Code Review https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/ bosu2015useful.pdf Code Reviews: Just do it https://blog.codinghorror.com/code-reviews-just-do-it/ Code Project - Code Review Guidelines http://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines%20and Great Example Checklist http://insights.dice.com/2012/10/31/whats-on-my-code-review-checklist/ Best Practices for Code Review https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
  111. 111. Resources & Additional Reading Rebecca's Rules for Constructive Code Review https://storify.com/ReBeccaOrg/rebecca-s-rules-for-constructive-code-reviews My Big Fat Scary Pull Request https://medium.com/@jdan/my-big-fat-scary-pull-request-2c8ac394540e#.yhs96vbxu Hacker School Environment & Social Rules https://www.recurse.com/manual#sec-environment
  112. 112. Example Style Guides Python https://www.python.org/dev/peps/pep-0008/ Scala https://github.com/paypal/scala-style-guide Javascript https://github.com/airbnb/javascript Google has many good, but strict style guides https://github.com/google/styleguide Doesn't matter which one you use. Pick one and stick with it.
  113. 113. Credits Special thanks to all the people who made and released these awesome resources for free: Presentation template by SlidesCarnival

×