There’re 3 areas that most developers wouldn’t/couldn’t do: unit testing, code reviews (or peer reviews) & refactoring. We know that they are necessary and important, but many of us are guilty of not doing them (or not doing enough). The most common reasons being: lack of time, not in the project schedule, it will be done in the next phase & QA team will catch the bugs.
This is still fall better than the minority who do not know anything about these. By not knowing, they won’t be doing it at all, and would even mistakenly feel that doing it is a waste of resource.
This article talks about code reviews. A typical code review could easily consume more than half a day without meeting the goal.
So assuming that you belong to the category that knows about code reviews and you do them (in any order of frequency), just what type of code reviews do you do? Do you:
- Check that the codes conform to a certain standard, like its format?
- Look for syntax errors?
- Find duplicated codes (arising from copy/paste)?
- Look for potential bugs?
If you answered yes to any of the above, do they take up a considerable portion of your reviewing time? Again, if your answer is yes, you’re likely to be doing it manually, instead of relying on tools & automation.
Code reviews should be done to ensure that the developer codes to specifications, and not those that I listed (at least not using bulk of your time). A developer, should be using modern IDEs such as Eclipse, together with a variety of plugins to help him do his work. And among such plugins are those that could help him do his own first level of code reviews, before putting up his codes for review with the team or his peer. The advantage of using such tools/plugins are: junior developers may not have the expertise to do the review efficiently; machine reviews a lot faster and on more classes that manual review; manual reviews may contain errors.
Now, imagine the scenario whereby your next code review is focusing on:
- Ensuring that the code does what the specifications say.
- Efficiency of the codes.
- The codes do not cause memory issues.
This would definitely be more productive, engaging and interesting.
To make it more useful, we can automate whereby at each nightly build, automated smoke tests could be run against all codes, generate a report and email it to the team. In this way, everyone is accountable for his work, and the team has visibility of the project. In a way, when the project goes into SIT or QAT or UAT, the confidence level would be higher.
Tools aside, code reviews will only work, if everyone put aside his pride and works objectively. Code review is not an attack on a person’s capability. Do not take it personally when your codes are reviewed and found to be not satisfactory. Instead, make it a point to buck up and show case a better piece of work next round.
Here’s the tools:
- PMD – an open source project that can be used independently or as a plugin, for finding bugs
- FindBugs – similar to PMD
- Checkstyle – an open source project to ensure that codes adheres to a coding standard
- PMD/CPD – PMD‘s copy/paste detector for finding duplicate codes; duplicate codes are a nightmare to maintain