What is it?
Peer review can be defined as the revision of code handled by another member of the team, different to the author of the original code. Its objective is to search defects and to propose and evaluate alternative solutions. Furthermore, peer review serves as a facilitator to spread knowledge across the team and if it’s the case, across the organization.
Where does it come from?
This technique can find its roots from the practice of publishing scientific articles where since the middle of the XX century takes prevalence in such process.
What things should I have in mind in a peer review session?
Peer review sessions look for the early detection of bugs, that’s why they should be performed in an incremental matter as more phases of the development life cycle are done. So it’s better to have many small peer review sessions throughout the development of the software than one big PR session at the end of the software life cycle.
The focus of a peer review session should always stay be the actual code at hand. The people around the code should not be the center of attention.
Starting from these principle it is possible to build systems more or less complex to peer review: basic systems where the revisions are made by a unique developer that takes the role of the reviewer, or where the review it’s made by a group of developers.
Focusing on the key elements
The value of peer review sessions lie on detecting the impact of new systems of development. That’s why, during peer review sessions one has to maintain the focus in the points that really matter.
- Are you following the principles of Object Oriented Programming?
- Are you correctly using the libraries and frameworks your are integrating, are you using one that is not standard?
- Can the code be refactored in a way that is more readable?
- Can one foresee issues with performance of memory leaks?
- Are we using correctly exceptions and logs?