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.

The Art of Giving and Receiving Code Reviews


Published on

Code reviews are one of the most effective tools we have, if we use them right. This talk discusses the technical, cultural and psychological factors that make for more productive code reviews and happier coworkers.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

The Art of Giving and Receiving Code Reviews

  1. 1. THE ART OF GIVING AND RECEIVING CODE REVIEWS Alex Hill (Imperial College London) @alexhillphd
  2. 2. Defect finding ● In a software-maintenance organization, 55% of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2% of the changes were in error. ● In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80%. ● A study of an organization at AT&T with more than 200 people reported a 90% decrease in defects after the organization introduced reviews.
  3. 3. Further motivation 1. Learning opportunities 2. Future proofing: ● Increase your bus factor ● Increase your Hawaii factor ● Ensure code is readable ● Maintain code standards Increase your bus factor
  4. 4. Review < 400 lines of code at a time Defect density = number of defects found per 1000 lines of code. Source: Cisco review study, practices-for-peer-review/
  5. 5. Review < 500 lines of code per hour Source: Cisco review study, practices-for-peer-review/ Defect density = number of defects found per 1000 lines of code.
  6. 6. Use checklists Are there unit tests? Does it follow SOLID principles? Do you understand it? Are there integration tests?
  7. 7. Use checklists
  8. 8. Code reviews as dialogue Source:
  9. 9. Understanding defensiveness
  10. 10.
  11. 11. Minimising unneccessary conflict ● Have clear code conventions ● Automate wherever possible: – Use a linter – Unit tests – Continuous integration ● Author reviews first
  12. 12. Conflict resolution styles
  13. 13. Lower defensiveness Raise ego
  14. 14. As an organisation we can... ● Pair program ● Discuss tasks prior to implementation ● Never silo codebases ● Emphasize teamwork ● Evaluate the code, not the coder
  15. 15. ● Use ‘we’ instead of ‘you’ e.g. “You should have re-used this function” →“We could re-use this function” ● Say ‘thank you’ ● Raise code by a grade or 2, no more e.g. C → B+, B → A ● Ask questions e.g. “We could re-use this function” → “Could we re-use this function?” ● Justify requests e.g. “Rename this to `getReportsWithFormattedDate`” → “Could we rename `getReports` to `getReportsWithFormattedDate`, to make it clear that the dates will already be formatted when it returns?” As a reviewer we can...
  16. 16. Give positive feedback! • “This is a cool library you found” • “This refactor makes a lot of sense” • “This is really easy to read” • “I didn’t know this function existed, thanks for bringing it to my attention!” Source: 2010/11/how-to-make-a-good-code-review.html
  17. 17. As an author we can... ● Practice the ‘as if’ technique – How would I respond if I were grateful for the feedback? – How would I respond if I were <Role model>? – How would I respond if this code was not mine? ● Say ‘thank you’ ● Annotate your review first ● Solicit feedback with specific questions
  18. 18. ● Optimise reviewer effectiveness ● Minimise unneccessary conflict ● Understand feelings of ownership ● Nudge towards collaboration ● Be nice to each other Summary