Understand why you are reviewing code and do it simply with Upsource

Do code reviews simply with Upsource

In our team we believe that code reviews matter. And yes, sometimes we find a potential bug, but the biggest benefit of reviews is getting people to understand each-others' coding style, keep conventions in sync, and learn about components others have developed.

We're using Upsource for automating the review process. Reviews are being automatically created each time someone commits and all commits having the same task number will end up in the same review. That way no commit will be missed. Reviewing is easy - you can:

• use different code comparison layouts
• leave your comments and questions
• and accept or reject what you just witnessed.

Upsource gathers commits related to the same task from all different code repositories, which is also great - for example, it lets you see front-end and back-end commits inside the same review. A good tip for Intellj users is to use the Upsource plugin: it lets you do everything without leaving your IDE! The plugin also notifies you if your review was declined or some comment was added so then you can react quickly. You can also pop up review comments in your regular coding window and that can really help you to understand the code better!

Ensure regular code reviews in your team

There are different tactics on how to ensure regular code reviews. Reviewing something that is old and in huge quantities loses many benefits that the review process has. It's gotta be fresh and it's gotta be quick! In our team, we have agreed on some ground rules - the main one being no review should be unattended for more than 3 days. We're using customized Upsource dashboards to have a quick overview of what needs our attention, but we also have used Upsource API to create a custom dashboard on our wall-TV. It shows some red/yellow/green colored boxes and if something is waiting, late, or piled up - then red flags will alert developers quickly. It's hard to sit at your desk, staring at the red box with your name on the wall and not act right away!

Upsource dashboard

We have also agreed that developers assign chunks of code to be reviewed themselves, so one does not have to review the very first commit. We like to commit often but we'd rather review a bit more stable understandable snapshot that is not subject to total refactor the next day. The balance here is important though, as reviews should not grow too big and too old. As we like continuous deployment, we decided that code review will not be blocking our production deploys, and we rely on automated tests and linters to catch most of the bugs. Our review process is voluntary; there is a shared pool of reviews that are out there for grabs and whoever has a moment to spare, can take the next one from the list. It usually works out quite nicely, but if some things start piling up, our TV will go red and scream for help!

Understand the WHY

No matter what the tools being used are, I think it's important for every team to agree on WHY they want their code to be reviewed. I've seen some cases where developers spend more time on reviews than on the actual code - trying to analyze every single character in order to find a hidden bug. I have also witnessed code reviewing as an order from above and people just scrolling through the lines without really reading them. Reviews can upgrade the code quality, keep devs on the same page, and possibly prevent bugs. But only if it's done effectively - otherwise it can quickly turn into an annoying waste of time.