Effective Code Reviews
According to Wikipedia Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several humans check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the humans must not be the code’s author. The humans performing the checking, excluding the author, are called “reviewers”.
Peer reviews are one of the most powerful software quality tools available to developers. When done right, this can assist in finding and resolving potential bugs. This stage reduces the more expensive process of handling, locating and fixing defects during the later stage of development or after solutions have been delivered to the users.
The misconception is that when doing code reviews, one only checks for potential defects, the solution design or whether the coding standards of the team are adhered. It’s understandable for developers not to deviate from the plan however reviews offer a unique opportunity for the development team which involves the following:
- Better code quality
- Early defect detection
- Knowledge sharing
- Improving the proposed solution
- Maintain consistency
- Opens discussion for strengths and weaknesses of a design
- Helps team members adapt their mental model of the system as it’s changing
- Domain knowledge awareness
As code reviews expose developers to new ideas and technologies, they write better code and better code. https://www.atlassian.com/agile/software-development/code-reviews via Atlassian
Reviews should focus less on how things are done or someone else’s preferences on how to solve a problem but should review the fundamentals and innovation. We all want code that is clean, that is well-formatted but that leads to a common problem of reviews being more focused on how the code is styled, spacing, just to mention a few but overlooking the logic. This may be caused by a lack of context from the reviewer and some based on how “things are done”.
Consistency of the code is good but it shouldn't come at the expense of best practices, fundamentals, and innovation. When writing code we must use our knowledge and creative thinking to come up with the solution, come up with better solutions instead of sticking to how have always been done. This will keep the job interesting and will encourage learning with respect to the architecture.
Who has the right to review? Every developer in the team, for junior team members it gives them an opportunity to learn the domain and more senior individuals are there to ensure that the architecture is not compromised, suggest better solutions, maintain code standards and identify potential bugs. This also gives everyone the opportunity to learn from each other, hold each other accountable in writing quality code and correct bad code habits.
Examples of bad software developer habits:
- No code structure
- Copy and paste blindly
- keeping unused code
- Names that don’t indicate the intended purpose
Code reviews are not to settle developer ego scores, be it that I commented on your code that forced you to make changes or to prove one’s seniority in the team, to make yourself visible to the “important” people when they decide to pull Github stats. Such behaviours create a toxic culture that discourages other team members from even reviewing. We need to understand that code reviews are a form of collaboration and we all have a common goal at the end of the day.
As a person being reviewed, it is important not to take the suggestions personal and it is also equally important to defend your solution if you feel it is better than what is being suggested. You must understand that the code is the one being reviewed not you and should not be taken as attack to your ability as a developer. Reviewers also need to be sensitive how they go about it and understand that at the end of the day everyone has to benefit from this process.
This is an open process where developers can share knowledge and improve each other's solutions. The review process can also be taken as an opportunity for the reviewer to let other developers know that they’ve done a great job when they’re impressed with the solution… giving each other props. These practices go a long way into building stronger teams and giving other team members confidence.