Once upon a time there was a project, where the quality of code was high and bugs were only in the ground. The end.
Nice story, isn’t it? Now back to reality. We are often dealing with situation when quality is not as important as it should be. Even more, its an „optional“ attribute of change requests, new features, fixes, etc. Even though there are some reasons for that, price for this approach is bigger than we are willing to admit. To produce a better quality software is always one of the goals at the beginning. However, at the bitter end, where deadlines are close, everybody is tired and stressed out, all that matters, is to deliver at least something we can build and won’t crush often. Well, there will be bugs, but will deal with them later. Does this sound familiar?
There are always several solutions to choose from and mostly there is a search for quick win. You can challenge me, but I think that code review is very effective quick win in most cases. Firstly, there is a rejection from developers. I like the idea there are two reasons for that in general. Programmer’s ego and hassle for packing, for quick delivery. On the other hand, based on „Best Kept Secrets of Peer Code Review“[1] there are these direct and indirect positives:
- Improved code quality
- Fewer defects in code
- Improved communication about code content
- Education of junior programmers
- Shorter development/test cycles
- Reduced impact on technical support
- More customer satisfaction
- More maintainable code
Thinking about this, another question raised. How to do it? Again, 5 types[1] (might vary depending on source) are here to help:
- Formal Inspections – Heavy process review with 3 to 6 participants meeting together in one room with print outs and/or a projector. Someone is the “moderator” and keeps everyone on task, controls the pace of the review, and acts as arbiter of disputes. Everyone reads through the materials beforehand to properly prepare for the meeting.
- Over the shoulder reviews – a developer standing over the author’s workstation while the author walks the reviewer through a set of code changes.
- E-mail pass around reviews – whole files or changes are packaged up by the author and sent to reviewers via e-mail. Reviewers examine the files, ask questions and discuss with the author and other developers, and suggest changes.
- Tool-Assisted reviews – process where specialized tools are used in all aspects of the review: collecting files, transmitting and displaying files, commentary and defects among all participants, collecting metrics, and giving product managers and administrators some control over the workflow.
- Pair Programming – two developers writing code at a single workstation with only one developer typing at a time and continuous free-form discussion and review.
Which of these five types suites you best is up to you. I honestly think it’s worth a try. „A successfully implemented code review process is a competitive advantage.“[1] Think about it. Share your opinion or experience.
[1] http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf
[2] http://smartbear.com/SmartBear/media/pdfs/WP-CC-11-Best-Practices-of-Peer-Code-Review.pdf
About author: Peter Šinkovič is certified Scrum Master (CSM) and works as a Solution Developer Expert at Erste Group IT. He is member of Agilia and organizes community events in Slovak Republic. .