I’ve just finished reading a book called “Best Kept Secrets of Peer Code Review” which is a free book, with free delivery from SmartBear who developed the code review tool called Code Collaborator.
You can get the book here
The book is quite short which makes it an easy read but has some very insightful views on the code review process. The title of the book is a little misleading as it suggests the book contains some content that isn’t already known to the wider audience. It doesn’t contain anything of the sort, but what it does contain is a very brisk overview what works with code review and what doesn’t, with some research and statistics to back it up.
As a developer we should already know the benefits of getting someone else to check over our work, we’ve all been there scratching our heads at a problem that we know should be easy to solve, yet for some reason you can’t see it. All it takes is for somebody else to look over your work and give back an objective opinion which will trigger you to realise what’s wrong, or in a case where you start to explain your work to someone and they don’t even get a chance to speak before you know what’s wrong.
In it’s simplest form this is a code review and in a more complex form you may print out pages of code to hand to other developers to read and point out any obvious mistakes. Both have pros and cons and are explained with good examples in this book. Finding the right balance for your work environment and staff is what is key to getting code reviews right.
So why don’t more teams have peer code review as part of their development process? There are a number of reasons that are explained but the one which I feel is the main objection to code review is the social aspects of what code review can mean to some people. In a lot of cases if the words “code review” are even mentioned it makes the author of code immediately defensive against the approach. “It will take me twice as long to do a check in”, “Don’t you trust me?”, “It’s a waste of time” etc. Some developers will think this is a way of measuring performance or quality of work, developers generally see defects/faults/bugs as a bad thing to be finding. Even before reading this book, I was one of the developers on the other side of the fence, I like to see other peoples work and give opinion, I also like other people to give opinion on my work. If I learn 1 new thing for every 10 times I ask someone to “look over my code” it’s worth all that effort on it’s own. If we also find 1 defect which means that’s 1 less ticket raised by testing or even worse, found by a customer, in my view this has always been worth the slight negative you may feel when someone finds a silly mistake you made. Defects are a good thing to be finding at any point in the development phase because it means less time spent testing and reimplementing the fix and retesting. This can easily be quantified into an actual cost which the book briefly explains and this can be used to justify the time/cost spent on doing code reviews in the first place.
When 2 developers get together to review some code and a handful of defects are found, we should see this as a very positive collaborative achievement and not be thought of as an exercise in embarrassing or undermining another developer where the defects were found. Developers all too often exist in a team but are very much a single entity and I believe code review is a great way to increase the communication in a team and also provide a way of increasing social bonds and not destroying them as many developers believe it will. Code reviews are about the code only, it is not about the reviewer showing he is a better developer because he found more defects in your code. The main goal is to produce a high quality product and the first step in doing that is producing high quality code with little defects.
This book has been a great refresher into why I love my job. The buzz you feel when your customer gives you some positive feedback and this book has helped keep fresh on my mind how we get this great reward. We produce high quality product to the customers requirements.
While I have done peer code review in the past, as i’m sure every developer has at some point, I for one have not used a defined “policy” in any one of my previous jobs. This is about to change, in my new job we cannot afford to have high QA costs and we certainly cannot afford to have lots of defects found by the customer. One way we hope to reduce this risk is by promoting the use of code review in our projects. We will try to encourage every developer to want to do a code review and not feel obliged to because it’s “process” but to help get the most out of code review we will work together to define a process which will guide us every time we do a review. This will be as much a team effort as the actual reviews are because we need every member of the team to buy into the benefits of peer code review or it wont work. Statistics cannot be used to judge a developers quality, statistics are used to show where you’re making the savings and highlight areas of common mistakes and reduce the amount of these that ever get to review.
My task now is to decide which style of code review we will encourage to our teams, document a process and define a guide to help reviewers and authors through the review process in the most efficient way.
I’m currently reviewing Smart Bear Code Collaborator which impressed me from the moment I set up my first review. It removes so much of the social problems, it almost removes the need to prepare for a review and it forces the review to keep on track and not get out of control. There are so many positives to using a tool like this I can see after doing only 5 reviews. I’m sure there are many more features I will find and I’m looking forward to seeing the statistics at the end of the trial.
Even if we decide the cost of the product is not in budget I will have benefited from using the trial as it makes it so easy to get people to buy into the benefits as soon as the first review ends.
When my trial is over I will post my findings and some details on what process we decided to take.
At the very least, if you’re a developer you should order this book. It’s free, it’s free delivery and it’s a short read. Pass it on to your team mates and try out some code reviews. They can actually be fun 