You’ve taken a test-first approach and your unit tests are in place. All your quality metrics have passed – code coverage, FindBugs analysis, etc. So why do you need peer review?
All good code has a cost and a reward. Peer review looks to reduce the cost by minimising the maintenance overhead and preventing bugs. At the same time it also provides an opportunity to socialise quality within the team. An experienced eye can spot problems early but an inexperienced reviewer can also spot patterns in your code that they can learn from.
One way to do it
Ideally peer review should start before development. The developer discusses their approach with a more experienced member of the team, or with the team as a whole, before any code is written in order to identify pitfalls early. If it’s an extended task then there should be regular catch ups. Once it’s done, the rest of the peer review ought to be straightforward. The reviewer should read through the code, highlighting any issues with the logic or tests that they spot and alerting the developer to potential design issues.
Peer review is an opportunity for the team to make sure it hits agreed quality benchmarks. Ownership is maintained: the reviewer recommends changes but it’s up to the developer whether to accept those recommendations.
Of course this isn’t the only way to do it. Pair programming, for example, provides another process for ensuring timely (and constant) feedback.
Peer review vs code review
I tend to use the term ‘peer review’ instead of ‘code review’ as the review should start before any code is written. As with anything in an agile team it’s as much about facilitating timely conversations as it is about coding per se.
Peer review is about investing in your team. It’s not about making one code revision better but rather mentoring one another to make the whole project, and every successive project, better.
Don’t show frustration
Peer review facilitates a conversation about quality and the tone of that conversation is important. Sometimes it can be frustrating to find repeated mistakes in the code. A good peer reviewer will highlight the good as well as the bad and strive to encourage others. You could be the most proficient programmer in the world but if you seem frustrated in peer reviews then it’s you that’s wrong. You may have seen the same mistake a hundred times but the peer review is not the place to let out that frustration, it’s the place to turn it around.
It can also be frustrating if other people read your code and suggest changes that you don’t think are correct. Bear in mind though, that others will have to maintain the code you write. If they can’t understand it then chances are the code is too complex.
What to look for
Always bring it back to maintainability, bug-prevention and quality. You’re looking to remove unnecessary complexity, improve readability, ensure agreed standards (e.g. code coverage, formatting, naming, automated testing), prevent bugs and make sure automated tests are useful and complete.
Peer review makes your product better. It makes your team better and it makes you better. If you’re working in a team then utilise that to your organisation’s advantage by using peer review to socialise quality – this will pay off for months and years to come.
Matt Harper is a software engineer who has worked in both commercial and public sector environments on a wide range of development projects. He has specific experience in Java, gamification of quality, app development and agile, with a particular interest in test driven development (TDD).
Personal pride, professional growth and increased compensation are the most popular reasons why professionals seek business and IT certifications. Learn about the IT Certifications that are available at Global Knowledge.