“Google engineer and former Harvard professor Matt Welsh does a great job of making the case for code reviews. I have never worked in a shop where code reviews were mandatory for every change, or even commonly held, but I’ve always wanted to for all of the reasons Matt Welsh explains. There are a lot of excuses for not doing code reviews, but I can’t think of any more efficient way to encourage developers to learn from one another and to develop a cohesive coding style that spans an entire team.”
A colleague suggests two apps for code reviews. One is what they use at Google, Reitveld, but also suggests that GitHub’s pull requests and commenting system could be another way to do this.
It seems that there are some barriers to doing code reviews, particularly in agencies. I’ve been thinking that it might be good to put an extra step in the code deployment steps that involves someone checking things before they are moved to the master branch to avoid and any bugs being introduced from code on branches. The current approach used at my job—where anyone on the team and push to master—feels like it introduces a failure point since deployments are typically done from master. I’ve seen this result in staging or production sites getting broken in places. This always reflects poorly on developers, but it seems like something we can avoid with tests, reviews, and an approval queue for code.