We push more than 250 commits every day. More than 30 people work on 15 projects. How do we keep the quality high and in the same time make sure that the best practices are spreading within the team and mistakes are not being repeated?
As we started to think about this problem we thought about code review. Seems like everyone knows that code review is a valuable tool but a lot of teams struggle with implementing it because of the overhead they feel they just can’t afford right now.
Here is how we keep the overhead minimal and make sure no one skips this very important step:
fast feedback loop - we review small commits and not finished feature branches. We might be missing the big picture from time to time and for that we do monthly retrospections but having fast feedback is more important
simple - we use an internal tool that pops up github commit view and allows to accept / pass or reject a commit in a couple of seconds. Accept means “looks good to me”, reject suggests that pushing this to production may cause some serious trouble and needs to be fixed ASAP, pass tells us “should work, but you can do better”
peer - we don’t have senior people review junior people. Everyone can review everyone’s code. It’s important so that we don’t introduce additional overhead for senior developers but also to keep the spirit “collaborative”
mandatory - as code review seems like an optional step we figured that unless there is an automated process that will force us to do it our will is not strong enough to keep doing it in times of approaching deadlines. Part of our process is pushing to staging server after each successful build. When there are rejected or expired commits (not reviewed within 48 hours) the staging server is not being updated and then we send a notification email to the team
part of the culture - everyone on the team needs to understand that one can “reject” the code but never the coder - people need to be free to give even harsh feedback if needed without worrying about offending someone
consistent styling guide - last thing we need is a 30 message thread about indenting style
Code review is usually seen as a way to keep the code quality high. We see it also as a way to encourage learning, spreading best practices and avoiding repeating the same mistakes. I our case the overhead is minimal (5-10% of the time is being spent reviewing other peoples code) and the gains are huge.