In the last post I described methods and practices to achieve higher code quality by improving the development environment in which a team works as well as by using different testing approaches which can be used by individual developers or independent tester groups. One additional method is to improve the quality of the code by doing code reviews on a regular base.

How can code reviews help to achieve better code quality?

• If another developer looks over code he/she can find architectural flaws or defects.
• Developers produce cleaner code if they know that somebody else will have a look at it.
• Design and coding guide lines can be validated
• Two pairs of eyes see more than one

Formal Code Reviews

Code reviews should be done on a regular base. This can be before mile stones in a project, before delivering code (cleaning up the code of a component), during prototyping in order to approve a design, etc. In this case the code reviews must be planned and should be part of the planning of an iteration (in scrum as a backlog item). Those type of reviews have a formal character and the results should be captured in a report or document which can than be distributed to the participants.

Peer Reviews

Peer reviews is are informal code reviews initiated by the developer which developed some code or a component. Another developer sits together with the initiator of the code review and they look together over the new code. The initiator can explain his code and work in ideas or directly correct found bugs. By doing so it is very important that the developer which is reviewing, does provide ideas and constructive criticism, but never destructive comments.

Pair Programming

Pairing up for programming is method which comes from Extreme Programming. It means that two developers pair up to develop a component at one workstation. This a consequent advancement of peer reviews. The person who is typing is called the driver whereas the other developer is called the observer or navigator. While the driver is programming the observer can already think ahead and find solutions for upcoming problems. This helps the driver to focus on the current task. The roles are switched frequently (e.g. every 30 minutes). This is important because otherwise the observer can loose the focus or is bored. Also the time of pair programming should be limited since it is very strenuous and developers have single tasks to do as well (e.g. answering e-mails).