Irrespective of how a project is managed, when an application is released and rolled-out, there can be a nagging question as to whether the application is performing efficiently. In any project, time pressures can force corners to be cut and short-cuts to be taken. At the end of day, if the features are operational and available, things must be ok – mustn’t they ?

In projects based on agile principles, code refactoring can be included, whereby the underlying code and not the features of an application’s functionality is reviewed and updated where necessary to make improvements to how an application operates. A proper and regular code review process helps to ensure that technical debt doesn’t build up in an application.

What is code refactoring

Code refactoring includes reviews and updates to an application’s code that cover;

• Improving the comments and structure of the code as to make it easier to read and understand the flow
• Eliminating any duplicate code routines to ensure that the code is easier to maintain
• Remove and/or recode routines so as to reduce the complexity of the code and ensure it runs more efficiently
• Identify any security weaknesses and remove/prevent any vulnerabilities by improved coding through better authentication, authorisation, error checking, and logging, amongst others

How to do a code review

A code review can be as informal or formal as you wish. In the OWASP Code Review Guide, reference to made to the following approaches, increasing in degrees of formality;

1. Ad hoc review
2. Passaround
3. Pair programming
4. Walkthrough
5. Team review
6. Inspection

To get further information on appropriate code review approaches, there is a code review case study in Best Kept Secrets of Peer Code Review. In this case study as possibly in our own experiences, lightweight reviews proved as effective as formal reviews for discovering bugs, but have the obvious advantage of being faster and more cost effective.

(Source: Marek Blotny's blog)

It’s important to realise that lightweight approaches such as pair programming or code walk-throughs, while informal can be very effective in garnering feedback when managed properly. Marek Blotny in his blog discusses an example of an informal, but structured approach for code reviews - the use of a ‘coding buddy’.

Application background is important

When looking at the degree of formality associated with each review approach, one principle is common and that is the importance of understanding the background to the application. In the OWASP Code Review guide, understanding the application includes being familiar with the purpose of the application and the audience for the application. This background information is very helpful in prioritising the areas of code to be reviewed and what standards of performance and security are required.

I appreciate that time is of the essence with all development projects, but even with a disciplined test approach, including unit, integration and user testing, some applications may still be vulnerable or nor running efficiently. An appropriate code review process, possibly an informal approach, properly managed can bring practical benefits.

Further reading

1. OWASP Code Review Guide v1.1 (v2.0 is planned for release later in January 2011)
2. Microsoft Code Review