Slides presented on the GDG Berlin Android.
https://www.meetup.com/GDG-Berlin-Android/events/fvvctlyzdbkc/
--
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.
2. The Art of Code Reviews
Fred
@tfcporciuncula
Anita
@anitas3791
David
@_dlazaro
Sebastiano
@rotxed
Lara
@lariki
Philipp
@tehultrah
3. 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, Second Edition — Martin Fowler
4. 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
5. What this is *not* about
http://adavis.info/2018/09/frustration-free-code-reviews.html
https://github.blog/2015–01–21-how-to-write-the-perfect-pull-request/
6. …and what this *is* about
• What we do to make them more efficient
• The ideas we use in our process
• How to be a happy person
• and much more!
How the Blinkist Android team does code reviews
8. 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 a lot about what you’re doing can easily keep
an eye on it
4. Early feedback FTW
22. 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
