This article summarizes some pitfalls to consider for maintaining quality code in a small development team, and makes a few suggestions in this regard.
Introduction
In a small team, with a high workload, there just never is enough time for a proper code review. So how do we ensure all code is up to standard?
Education
Shockingly, coding standards were not covered in my tertiary degree, nor in any educational course I had completed over the past 15 years. I see the same shortcoming in most mainstream developers. There is no foundation laid for how to ensure code is of a good quality.
So let's just peer review our code then, right? "I'll o.k. yours if you o.k. mine"
Well if it's taken a dedicated resource 10 days to write a complex set of classes, interacting data to a GUI somewhere, with specific business domain rules built into it, based on weeks of workshops and pages of requirements and technical aspects, can I then really claim I've reviewed it after spending an hour scanning through it looking for obvious problems? I can't. I need to understand those business domain specifics, I'll need to understand the data structure, I'll need to understand the architecture of the application as a whole as well as the specific developer's preferences, and for this I'll need far more time than what a small team with an overflowing inbox has available.
There is no clear answer for this. I can tell you what works for me though, from personal experience.
SCRUM
Increased agility and short sprints allows me to get involved and see the actual code regularly. I then don't need to understand a large piece of work, but rather its subsets, smaller fragments of the bigger picture and can intervene early when I spot a flaw, thus instilling positive coding habits with individuals in my team, without taking days out of our productive, money earning schedule.
In my opinion, peer code review, as a technique for quality, scalable and maintainable code, is only effective in this environment, in any other, it becomes superficial and ineffective.
Automated code analysis
It's quick to point out flaws and missed standards based on your requirements. It's unemotional and to the point and its findings can be solved by the code owner before you even need to look at his or her code through peer code review. This works well if used in a project from day 1, but becomes useless if added into your process later in the life cycle, as you will now sit with an existing code base that does not adhere to these rules and you will lose precious development time to align this, while destabilizing code that has in all likelihood gone through some testing.
So to summarize
Don't try and review code once a month. Do it frequently.
There are tools out there, use them from the start. Prioritize the inclusion of these tools in your development process as well as your budget, and if KPIs are part of your responsibility, include the use of the process and tools in those KPIs.
DISCLAIMER
I did not venture into review checklists or standards documentation for this article. That is a discussion on its own and one I cannot attempt this early in the day.