You’ve just finished a nice piece of code that you feel satisfied with committing, what is the next step?
The answer is Code review, wohoo! Code Review also known as ”Peer Code Review” includes a couple of useful techniques for systematically convening with other programmers to check each other’s code. Because we’re humans we make mistakes. You don’t want to commit bad code that could cause problems or conflict with others code in the software. Checking your own code is not always sufficient as you might miss problems that you don’t find important or didn’t think about. If you let another programmer check your code, that person will most likely find more problems than you.
As a reviewer you typically check for the following:
- Are there any obvious logical errors in the code?
- Are all use cases fully implemented?
- Do existing automated tests need to be rewritten to account for changes in the code?
- Does the code conform to existing style guidelines?
If your team is working using task branching workflows like Git, then you typically want to have a code review before the code is merged upstream. This is a good way of catching the bugs and other mistakes that the automatic tests sometimes miss. Without this practice your team risk polluting the main branch line of the code.
Code review can be done in multiple ways:
This approach of writing software empathizes that developers should work on the same code together side by side, checking each other’s code continuously. This bakes the code review into the programming process. One of the cons of implementing this practice is that it requires more resources than other methods. You could also argue that it’s not very objective as the reviewers are very close knit to the code.
When you want to commit the code you’ve written you send the code to the appropriate colleagues via email. This practice is a bit more flexible than convening with all colleagues in the same physical place to inspect code. The problem with this approach though is that email discussions with many suggestions and differing opinions can become really complicated, which can make it difficult for the original coder to sort through it all and decide which suggestion is the most appropriate.
This technique is in my opinion the easiest way to review code. When you’re done with your code you simply just ask a team member to sit down with at his or your desk and review the code with you. You should be present during the review and explain to the reviewer all your coding decisions. This is probably the most informal and lightweight approach. I personally think this is most suitable when you are committing smaller amount of code.
Code review is fun right?
Code review can be a real pain to do and sometimes even cause strains on interpersonal relationships in the team. Many find it annoying and difficult to have all their code critiqued by peers. Therefore it’s important to foster a positive code review culture where errors found during code review isn’t used to evaluate team members performance.
I think code review is very beneficial because it help facilitate knowledge sharing across the code base and across the team. When you reviews someone else’s code both you and the person learn from each bug or problem you solve.