Code Reviews

We’ll look at code reviews both from the author’s and reviewer’s side. How to prepare a pull request that gets reviewed quickly and whose review is pleasant? And how to perform reviews that are both efficient and useful? Along the way we'll discuss some common anti-patterns in Jut’s code which good reviews can prevent.

Presented at internal Brews & Clues session at Jut.

Transcript

1. Code Reviews How to get an instant +1 and make reviewers love you David Majda (@dmajda) Feb 20, 2015
2. Intro
4. Preparing PRs Reviewing PRs Code smells
5. Preparing PRs
6. Make PRs small
7. Easy to review Don’t rot so quickly Less conflicts Less breakage
8. Atomic Incremental Features / Refactoring / Formatting Controversial / Non-controversial
11. Advise reviewers
12. State Assumptions Focus areas
15. Use commit messages
16. http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
17. Reviewing PRs
18. Do I get it?
19. Checklist
20. High-level
21. Best approach & design? Proper level of abstraction? Change isolated?
22. Mid-level
23. Already seen this? Easy to maintain? Easy to extend? Not overengineered? Boy scout rule?
24. Low-level
25. Are errors handled? Covered by tests? Follows coding style? Bugs: other occurrences?
26. Code smells
27. Long functions
29. No modularity
30. No interfaces
31. That’s it!