When organizations look to improve the quality of their software, they have a wide range of potential objectives: Making better software may mean eliminating defects, adding new features or building a product that can get to market faster. Given the occasionally subjective nature of assessing software quality, the best approach to ensuring success can vary, software consultant Johanna Rothman explained in an interview with Dr. Dobb’s. A technique such as peer code review or even collaborative, paired coding can be an effective way to meet goals that are qualitative rather than quantitative.
“I’m a huge fan of unit testing, feature, and integration testing from developers,” Rothman told the publication. “Pairing improves the people’s ability to see the whole system as well as improving the quality of the code. If people aren’t ready for pairing, then peer review of some sort.”
The idea of code review can conjure negative images of long, grueling meetings in which developers have their carefully crafted projects raked over coals, but a properly implemented peer code review can improve overall quality without damaging egos, agile development expert Catherine Powell wrote in a recent Dice blog post. She emphasized that peer code review should be a learning tool that helps developers on a team catch each other’s mistakes rather than a way of exposing team members to criticism. To achieve this type of positive learning environment, development teams can adopt these three code review practices:
1. Everyone participates: Nobody should be seen as too junior to offer useful commentary or too senior to be critiqued, Powell suggested. By bringing everyone – even the interns – into the code review forum, teams can access more insight and spread more knowledge. Less experienced team members will be able to learn more and feel more trusted if they are actively participating in code reviews, and it may be the newest hire whose fresh perspective helps spot a bad habit others on the team had begun to take for granted. For similar reasons, code review teams should not be limited to set pairs.
“Make an effort to review code in an area you haven’t looked at before,” Powell wrote. “Sure, the reviewer will ask a lot of questions, but it will flush out assumptions, and everyone will learn a lot.”
2. Reviews are public: Many segments of code are probably going to be of interest to or require the expertise of more than one member on the team, and holding reviews in a forum that facilitates collaboration can have powerful results, Powell noted. By making reviews visible to everyone, the whole team can learn from mistakes or offer suggestions, which means that the final product is likely to be stronger and the net knowledge of the team is likely to be greater. Feature-rich code review tools that offer a social component allow teams to work through problems together and ultimately create better code.
3. Everything is timely: To avoid creating a backlog and letting code review sessions turn into lengthy, boring meetings, businesses can use tools that accelerate the process of handling review requests. With a dedicated code review tool, developers can track requests and ensure they are responding in a timely fashion.
“Peer code reviews can be a real bottleneck if they build up; it’s much better to take them as they come in,” Powell wrote. “And in the end, a code review makes a good thing to do when you need a break from a hard problem or when you’re transitioning between tasks.”
Leveraging peer code review tools and best practices, businesses can ensure that their software quality remains consistent while continuing to educate their team and to incorporate the insight of different stakeholders.
Software news brought to you by Klocwork Inc., dedicated to helping software developers create better code with every keystroke.