At Gitcolony we are huge code review fans and evangelizers! “Get out of the building” is the best way to build a product and we do that every day. Based on these conversations, we work hard to improve our product and make the code review process a much more effective, easier and faster process.
What’s wrong with code reviews? There are no actionable items and there is no traceability in most companies’ code review processes.
You need actionable items
If your code review process doesn’t include actionable items, you are doing it wrong. I heard about companies that after having one of their senior developers spending half a day reviewing code, they had to send an email to the rest of the team with a list of issues and improvements to include.
Developers, in general, are not very “email-friendly” and at the same time emails get lost, so…can you imagine the final result? Yes, everything stays the same way!
Gitcolony helps you define actionable items. We detected this issue and worked hard to create an straight-forward flow; select a line (or multiple ones) and create an issue directly associated with your preferred issue tracker with just 1 click. You can afterwards define if it’s blocker or not to merge your code into your main branch.
No more lost emails, no more internal TODO lists, just create your tickets directly from the place where you are reviewing your code! No more excuses, it’s actually really easy ☺
Traceability: Code Review Coverage
We have heard many times that code reviews don’t have a deliverable so it’s hard to track them and understand how much time someone in the team spends reviewing code. Many developers sending emails like this one: “I took a quick look at everything, we are ready to go to production”. Again, here is where my questions arise, what does “everything” exactly mean? Are you sure that you took a look at the right code?
With Gitcolony we defined a rich timeline where you have all the information you need at hand to make better data-drive decisions and we track exactly all the commits you actually reviewed, so we can accurately say which commits were reviewed and which ones weren’t.
With this in mind, we defined a new KPI that we consider should be included in any software development process: Code Review Coverage. The same way we are used to measure our test coverage based on the code paths covered by unit tests, we can measure how much of our code is reviewed since the process is now traceable and measurable!
Code reviews are super important, but in order to make them work you need to set clear actionable items and a way to easily track them.
“If you can’t measure code reviews, you can’t manage them nor improve the process”
