The Art of Code Reviews

(This talk was presented at Droidcon Berlin 2019, but unfortunately the video recording was lost)

Code reviews are a fundamental part of our job as software developers. Every piece of code we write is (hopefully) carefully reviewed by our teammates before becoming part of our systems. It's an important part of the development process, and it requires significant time and effort.

While a great review experience will promote interesting discussions, ensure consistency in the codebase, and potentially catch bugs and implementation oversights, a poor review might lead to nasty bugs and unhappy developers. Still, sometimes it's hard to find the motivation to thoroughly review a pull request, and eventually it just doesn't seem to be worth it given the time you'll need to spend and how hard it usually is to properly review those huge PRs that pop up every now and then.

In this talk you'll learn strategies and guidelines that will help improve the efficiency of your team's code reviews. We'll talk about work in progress PRs, commit by commit reviews, emoji driven comments and more. You'll listen to great (and scary) tales of code reviews experiences, and lots of tips and tricks when it comes to preparing the perfect pull request for your peers.

https://www.de.droidcon.com/schedule

Transcript

1. The Art of Code Reviews Fred @tfcporciuncula
2. The Art of Code Reviews Fred @tfcporciuncula Anita @anitas3791 David @_dlazaro Sebastiano @rotxed Lara @lariki Philipp @tehultrah
3. Code Reviews ! ! !
4. Some organizations do regular code reviews; those that don’t would do better if they did. Code reviews help spread knowledge through a development team. Reviews help more experienced developers pass knowledge to those less experienced. They help more people understand more aspects of a large software system. They are also very important in writing clear code. My code may look clear to me but not to my team. That’s inevitable — it’s hard for people to put themselves in the shoes of someone unfamiliar with whatever they are working on. Reviews also give the opportunity for more people to suggest useful ideas. I can only think of so many good ideas in a week. Having other people contribute makes my life easier, so I always look for reviews. Refactoring 2nd Edition — Martin Fowler
5. Some organizations do regular code reviews; those that don’t would do better if they did. Code reviews help spread knowledge through a development team. Reviews help more experienced developers pass knowledge to those less experienced. They help more people understand more aspects of a large software system. They are also very important in writing clear code. My code may look clear to me but not to my team. That’s inevitable — it’s hard for people to put themselves in the shoes of someone unfamiliar with whatever they are working on. Reviews also give the opportunity for more people to suggest useful ideas. I can only think of so many good ideas in a week. Having other people contribute makes my life easier, so I always look for reviews. Refactoring 2nd Edition — Martin Fowler
6. https:/ /twitter.com/relizarov/status/1123586265054699520
7. What this is *not* about • How to write comments • How to respond to comments • How to be empathetic and sensitive • How to not take it personally
8. What this is *not* about https:/ /github.blog/2015–01–21-how-to-write-the-perfect-pull-request/ How to write the perfect pull request http:/ /adavis.info/2018/09/frustration-free-code-reviews.html Frustration-Free Code Reviews
9. …and what this *is* about • What we do to make them more efficient • The ideas behind our process • How to make your life easier • and much more! How the Blinkist Android team does code reviews
10. The WIP PR
11. The WIP PR
12. The WIP PR
13. The WIP PR 1. You do a tiny bit of work and open a PR 2. Everyone knows what you’re doing 3. People who care about what you’re doing can easily 
 4. Early feedback FTW keep an eye on it
14. The WIP PR 1. You do a tiny bit of work and open a PR 2. Everyone knows what you’re doing 3. People who care about what you’re doing can easily 
 4. Early feedback FTW keep an eye on it
15. The WIP PR
16. https:/ /github.blog/2019–02–14-introducing-draft-pull-requests/
17. https:/ /github.blog/2019–06–26-ask-students-to-iterate-with-draft-pull-requests/ The WIP PR
18. https:/ /github.blog/2019–06–26-ask-students-to-iterate-with-draft-pull-requests/ The WIP PR
19. The WIP MR
20. The WIP MR
21. The WIP MR https:/ /about.gitlab.com/2016/01/08/feature-highlight-wip/
22. The WIP PR
23. The WIP PR
24. The WIP PR https:/ /ben.straub.cc/2015/04/02/wip-pull-request/ The WIP Pull Request
25. Small PRs
26. Small PRs
28. Squash? Merge? Rebase?
29. The ideal world
30. Squash? Merge? Rebase?
31. Squash and merge will make you lose your (beautiful?) commit history. But if your PR is small enough, then that’s fine.
32. Commit-by-commit reviews
36. A PR is like a presentation, and your slides are your commits.
44. Commit-by-commit reviews It really helps with: • Presenting your changes in assimilable chunks • Unrelated, automatic changes and refactoring • Big PRs
45. The ideal world… doesn’t exist :(
46. Commit-by-commit reviews Two options to reach a commit-by-commit reviewable PR: • You’re can either build a beautiful commit history from the beginning • You rewrite your commit history before opening your PR
47. It’s fine to have an artificial commit history, as long as it helps the review process.
48. Commit-by-commit reviews
49. • Rebasing while reviews are happening • “I'm fixing that in my next commit" • It works better on change-intense PRs • It takes some time to get used to it Commit-by-commit reviews
50. “I'd never go back!” — Someone from the Blinkist team
51. Extra bits
52. Extra bits 1. Create great descriptions 2. Have a good PR template
55. Extra bits 1. Create great descriptions 2. Have a good PR template
56. Extra bits 4. Embrace self-reviews 5. Keep PR list clean 6. Emoji driven comments " 1. Create great descriptions 2. Have a good PR template
57. # driven comments ❤ – Praise and compliment % – Suggest ideas ❓ – Ask questions ' – Nit-picky comments ⚠ – Warn and express concern ) – Blocker!
58. # driven comments
59. # driven comments
60. # driven comments
61. # driven comments * * *
62. Summary • WIP PRs • Small PRs • Commit-by-commit reviews • Keep things clean (and maybe use %, ❓, ')
63. Good pull requests are an act of empathy, for both the author and reviewer.
64. Good pull requests are an act of empathy, for both the author and reviewer. https:/ /slack.engineering/on-empathy-pull-requests-979e4257d158
65. Thanks. @tfcporciuncula bit.ly/droidcon-code-review
66. bit.ly/ droidcon-code-review @tfcporciuncula