Since the last lesson, a second person reads every pull request of the Kladde before it gets onto main. How to write a review on
GitHub and how to stay friendly and precise, you know from lesson 1.7.4. This lesson is about the content: what does a review look at, in
what order, how much at a time, and what do you do when you can’t agree? At the end you review a prepared pull request with six flaws
hidden in it, and the Kladde gets its review checklist.
What a review is for
A review has three jobs:
- Finding mistakes before they’re on
main. Four eyes see more than two, especially when the two wrote the code and therefore read what they meant instead of what’s there. - Sharing knowledge. After the review, two people know the change. If one is out, the other can keep going.
- Keeping the shared rules. The house rules and the definition of done only apply as long as somebody looks.
A review isn’t an examination of the person and not a gate where somebody has power. Whoever wrote the code stays responsible for it. The reviewer helps with that.