Here at Codelitt, we have a basic rule: all new code must be peer-reviewed before being merged into production. If you’re still not doing this in your organization, I highly recommend you start to. It doesn’t take much planning, and the rules are simple. Initially, it’s enough to have anyone on the team review the code you wrote. Just from doing that, many (but not all) bugs will be caught, preventing something potentially dangerous down the deployment pipeline.
However, there is more than meets the eye when it comes to doing code reviews. In fact, there is interesting research that’s been done on this topic, suggesting that code reviews are indeed a valuable tool in software engineering 1 2. These provide some interesting metrics that you should consider if you want to have effective code reviews. Based on my experience, I feel that the following suggestions are very true:
You only get effective code reviews when you do them at a pace of 300-500 lines of code (LOC) per hour. This varies a lot depending on the type of code being reviewed, the style of the original developer, and the person reviewing the code. But the point here is that there is a limit to what we can actually take in when reviewing code.
Almost as a corollary of the previous statement, you shouldn't review much more than 200-400 lines of code at a time, and don't spend too much time in each batch, at least not more than 60-90 minutes.
It's important to highlight that you will have to account for additional time being spent in the development process to do code reviews. Code reviews should be considered as important as writing the code, and therefore should be considered when planning the ETA. As usual, having frequent, incremental commits helps with this.
Besides the previously discussed figures, the aforementioned studies also found some best practices when doing code reviews. Again based on my experience, the following are the ones that work the best:
Code review are an opportunity to assess the knowledge of coworkers, transfer knowledge, and share 'tricks of the trade'. For example, you might have developed a clever solution to a common problem, whereas a coworker is using an effective but inelegant solution. This is an opportunity to teach him and help improve his skills. It also helps to convey the standards and coding style that is used in the organization.
When adding comments, explain clearly what you mean, and try to provide code to support your ideas. This code doesn't need to be tested, it just serves to convey your idea.
If possible, pull the branch and execute it locally and actually test the code, even superficially. There's not a single time that I've done this that I haven't found something that wasn't working as expected. Then, instead of just reporting it directly to the person responsible for the change, do a little of extra work and try to find the place in the code where to leave a comment about this. It's not about finding the root cause of the problem, but to at least provide some useful context for the problem that you discovered.
Finally I'd like to highlight something that is usually bypassed: the human factor involved in code reviews. In my opinion, you should be always extremely polite, never be sarcastic and of course never undermine the work of a colleague, or otherwise the process of code reviewing will have undesired (some times devastating) side effects on the team as a whole.
Download our Incubator Resources
We’re known for sharing everything!
Save more time, get more done!
Innovate from the inside
YOU MIGHT ALSO LIKE