Manual Code Review used to be

The established standard is one write the code, and another one review it. This is safe and sound: no one can both be judge and be judged. Times are changing and they won’t stay long that way.

Manual code reviews are definitely good for team building : obviously, experienced developer find more issues than a novice, but novice are able question the obvious or bring in fresh ideas. And, even more important, they learn so much by checking other’s code, learning both from their success and their errors.

Manual review are expensive

How rich may be manual review, it usually hits two snags : first, the volume of code that needs to be reviewed. Nowadays, even small projects may pass the hundred thousands lines of code. This is difficult to review the code systematically and often. The second is the amount of small errors that are not worth the review time. Think about non-compiling files or features from the next PHP version finding its way in the current code. This is quite easy to spot, fix and it should not have to be humanly reviewed.

This is where the industrialization of code review starts. Quite a large number of those innocent mistakes may be trapped by static analysis engines. Such tools mimic the way we check code : by reading it, without executing it. This saves the time to set up a testing environment, and provide some quick feedback on the code.

Recommendations comes from various aspects

The feedback shall cover several aspects of the code, as it is produced in your environment :

Everything that may be automated by some analysis tool is worth externalizing. This leads to increase the consistency of the code, and free time for more complex problems during manual code review.

Static analysis is helpful

In the coming years, static analysis will emerge and make its way into the continuous delivery process, as a simple but useful too. Manual reviews will then shift closer to complex issues and business priorities.