Tom McAdam

code reviews: an update

Last year, Max wrote about how we review code here at MetaBroadcast. A bit has changed since then, so today I’m going to recap and let you know what we’re up to these days.

pull requests and code reviews

Code reviews take two forms. Firstly, we use pull requests to give feedback for changes before they make it to the master branch. We don’t insist on a pull request for merges to master, but it’s up to whoever wrote the code to decide whether they’d like someone else to give it the once-over. A one-line configuration change may not need it, but if there are a bunch of changes being made, they’ll likely want at least one other person’s opinion.

Secondly, we get together once a week during Happy Hour to have a longer discussion about a recent set of changes. The whole company gets involved in the weekly reviews, and the code or technology may not be familiar to everyone.


To help out those of us that haven’t come across a particular thing before, we now have code review briefings on a Monday. They help by providing a primer on a couple of topics. To give you a couple of examples, we’ve recently talked about HTTP status codes and why they’re important, and given an overview of Express.

During Happy Hour on a Tuesday, the person whose code will be reviewed on Wednesday takes the 10-minute demo slot to run through some specifics about the code: some background on the project, a run-through of the changes (the API changes that resulted, a tour of the front-end), an overview of the code, and any particular areas they’d welcome feedback.

The team provide their feedback, which is then collated and used as the basis of discussions on Wednesday, which last around 45 minutes. We try to pick out a range of things, from a logic bug through to larger questions about whether a particular design pattern should be used.

We find the combination of pull requests and a weekly discussion is a nice balance for code reviews. The discussion format once a week gives us a great forum to get together and talk about a range of things, collectively hone our style guides, and encourage the feeling of team ownership of the code.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.

blog comments powered by Disqus