Subscribe via RSS Feed Connect with me on LinkedIn

Streamlining Code Reviews With Bitbucket

[ 0 ] June 13, 2013 |

Code reviews are an important part of the development life cycle, yet they are rarely implemented. Time is usually the key factor when it comes to doing code reviews. Back in the day, we didn’t have nice tools available to us like Crucible, so we use to print out pages and pages of code and sit around a table and go over the code with fellow coders. Not only was it not very environmentally friendly, it was also very boring and ineffective! Fast forward to today, there are plenty of tools to choose from that will make code reviews effective and less obstructive.

So with all these great code review tools available, what’s the problem? The problem is that these code review tools have their own life cycle… there are several steps required to setup a simple code review, and the code reviews need to be managed themselves. That doesn’t sound too bad, but in a fast paced environment where time and budget need to be respected, there will always be something higher up on the priority list. Another problem I see with code reviews is that they are performed at the end of development, so often there is a lot of code to review which makes it a daunting task. Also it would be nice to get feedback as you are developing instead of just at the end!

Our approach to doing code reviews is a simple one: we are taking advantage of Bitbucket‘s inline comments, approval and notification features. Here are the basic steps:

1. Review the code
You can set up email notifications for all commits. This way, as soon as something is checked in, you get notified and you can review it right away. Unlike a traditional code review where you are assigned to review several pages and hundreds of lines of code at once, this way you only really need to review the diff. Makes it quick and easy!

An alternative to reviewing on every commit, is to perform a code review when a ticket is closed. Assuming that each commit message is tagged with the associated ticket number, once that ticket is closed you can review all the commits tagged with the associated ticket number.

Commits

2. Make comments
You can add inline comments to the code, which will notify the coder via email notifcation. The trick here is how you make the comment. Not all comments are created equally! So what you can do is prefix the comment with a tag.

You can come up with your own tagging scheme. The point of the tagging is to quickly let the coder know what action needs to be taken, if any at all. If no tag is prefixed with the comment, then no action is required, and is simply meant for discussion. Take a look at the following examples:

Bug

Standard

3. Approve
Once you have completed your review, simply click the Approve button at the top of the page.

Approve2

Of course this streamlined code review process doesn’t have all the bells and whistles that a product like Crucible has… but it gets the job done, effectively and efficiently! And most importantly, remember why you are doing a code review:

  • To ensure company standards are being followed
  • To ensure unit tests are adequate
  • To suggest improvements
  • To share knowledge
  • To learn about code base
  • To find bugs

Tags: , , , , , ,

Category: Blog

About Kaveh Eshghi: I am currently the SharePoint Development Lead at Dynamic Owl Consulting. I got involved with computers at a very young age and I fell in love! I graduated from SFU with a degree in Computer Science and have been writing code professionally ever since... View author profile.

Leave a Reply




If you want a picture to show with your comment, go get a Gravatar.