Code Critique

A constant in the life of a developer is the code review, you have completed your assigned task and now you must ask the rest of your team what they think of your efforts.

There aren't many occupations where on a daily basis you openly invite criticism of your work, there are many aspect of development that are more art than science and so asking others for their opinion of your labours is not always done with relish.

However, the purpose of a code review shouldn't be ritual humiliation or driven by a strong desire to find fault, it has many benefits to an effective software development life cycle.

Automate the Mundane

For a code base to have a level of consistency its important that a common coding style be prevalent, one of the items that a code review should cover is conformance to this style but it shouldn't be the responsibility of the other developers reviewing the code to enforce this.

As well as developers the other reviewers should be automated tools who can be relied upon to ensure the agreed upon code style is being adhered to, it is not optimal to have your experienced and talented developers talking about the placement of brackets or the indentation of a code block.

It is also not practical to expect even the best developer to be able to review a piece of code and identify all or any possible bugs that it may introduce, instead another automated reviewer of your code changes should be your unit test runner.

Catching bugs at the earliest possible opportunity is desirable and catching them before they are merged in is about as early as can be.

A Tool For Education

Code reviews aren't just about gatekeeping they are also an opportunity for education both for the person submitting the code and for the people reviewing it.

They represent a good opportunity to demonstrate new thinking on an old problem, smart thinking for a new feature or a post mortem on the cause of a bug.

They can also be a tool for education on architecture, the history of why code is the way it is or a pre-emptive intervention to prevent a possible new bug.

Agile is all about communication, in its purest form this is face to face but in a contemporary development setting code reviews are as good a place as any.

If this communication channel is being used effectively you should be able to see a change in the topics of conversation as the understanding of the code base and the principles behind it grows within the team.

Observation Over Criticism

It can be easy to fall into a critical mindset when reviewing code, to assume that your role here is to find fault and criticise.

The nature of coding means there is nearly always more than one way to solve a problem, some alternative solutions will be flawed but many will simply come down to a question of style or artistic preference.

Don't approach a code review with an aim of criticism, you should have enough faith in every member of your team as to not assume that a code review is required to stop bad code making it into the code base.

Instead see the code review as an opportunity for observation, could some efficiency be gained in this area? Is there the potential for a bug here? Haven't we done something similar to this before?

The opportunity for a code review to be an educational tool should mean that the aim is not just to review the code currently being presented but all to influence the code a developer will submit in the future.

Developers are human like everyone else they will react better to honey than vinegar, don't create an atmosphere where code reviews are a tool for them to beaten with but an opportunity to learn, an opportunity to influence and an opportunity to shape future code reviews.