[WORK IN PROGRESS] Code review guide

[dbader]

@elbaschid found this fantastic code review guide by the folks over at Thoughtbot.

When we read through it we felt like it matched Mobify's idea of doing code reviews very closely. We'd like to propose this guide (potentially with minor adaptations) to be included in the mobify-code-style repo.

Thoughts?

To do

• [x] Tailor the style guide so it fits Mobify
• [x] Include things already mentioned on Confluence
• [ ] Get some early feedback
• [ ] Discuss this at next Science Fair
• [ ] Merge
• [ ] Reference this on Confluence/Confluence Questions/Onboarding guides/...

[benlast]

Additional comment... taken from a StackOverflow answer:

Some objective study (Fagan, etc.) and a lot of popular wisdom suggests that peer relationships facilitate code reviews aimed at reducing bugs and increasing productivity. Working managers may participate as workers, but not as managers. Points of discussion are noted, changes to satisfy reviewers are generally a good thing but not required. Hence the peer relationship.

This (to me) echoes the point I was trying to make above: reviews are to help the author, not to try and control what they have written.

If you have rules, you'll have foolishness, they are inextricably linked. Any rule's benefit should be worth the foolishness it costs, and that relationship should be checked at regular intervals.

Here I was initially unclear what the writer meant by "foolishness" - I think it's referring to the mental costs of staying aware of the rules and following the rules. The more rules, the higher that cost. If the rules are about trivialities, then we're spending expensive developer time on those trivial matters. I don't think we should be doing that.

Review is better, as the Agile Manifesto notes, relationships are more important than process or tools.

And that, more or less, is why I'm rattling on about this stuff. The relationships between developers, as peers with mutual respect, are amongst the most important things for our team to develop and maintain. Bad review practice risks damaging those relationships.

[dbader]

Just found this article and I'm thinking maybe we can incorporate some of it into the "code review mindset" section: https://medium.com/medium-eng/the-code-review-mindset-3280a4af0a89