Code review is the systematic examination of a software product’s source code in order to discover mistakes that might have been overlooked in the initial development phase. Doing so allows the developers to rectify errors in the code as they are discovered, thereby improving the overall quality of the code. This, as you can imagine, is a rather exhaustive process in which the developer who does the review, reads the code line by line to check for bugs or potential problems in compliance with coding standards and best practices. Issues once discovered are communicated to the developer who did the original coding through email or tools such as GitHub or BitBucket. The image we found whilst reading Beller and Juergens (2014) does a good job explaining this.
Regular code reviews as we mentioned earlier brings a host of benefits to the project, the developers and the client. Provided below are 5 such benefits of code reviews that we at Mood Up see every day.
1. Help reduce bugs – A single overlooked bug can kill a project that’s been in the works for months for thousands of dollars. That’s why we utilise another developer to help discover bugs that might have been overlooked by the original developer. Such regular discovery of bugs allows the team to fix them and reduce the time the QA has to spend on testing.
2. Improve code readability – Delivering clean code is important in any software development project as the developers who take over a project with no prior exposure to it should be able to understand it speedily and not spend time trying to decipher it. Code reviews assist in this as they help improve the readability of the code by having a developer with fresh eyes go through the code.
Pro tip when hiring software developers– take a look at their previous code. Clean code is a good practice all developers must cultivate and is an indicator of their competencies.
3. Create a shared coding standard – There is no one way to solve the requirements our clients request of us. Some ways, however, are better than others and coding reviews from senior developers help to discover better approaches to solving problems. Such standards help to create shared coding standards, keeps us on our toes and create a culture of continuous development that is reflected in the code we develop.
4. Creates accountability – We perform our best when we are held accountable for our actions, and coding is no different. Code reviews ensure that the developers produce their best work in order to display their competencies to their peers. The developer who does the reviewing then does the same, creating a circle of accountability throughout the organisation.
5. Double-checks to ensure all coding requirements have been filled – Regular reviews of the code ensures that no requirements go amiss and all that’s required is what is developed. This also makes the job of the QA easier as some requirements are difficult to produce during tests and much easier to verify within the code itself.
So, how can you ensure a code review goes as it should?
1. Make your commit message as clear as possible – The commit message from the original developer should highlight what was fixed or added to the code, allowing the reviewer to verify it. It’s for this reason that we follow established guidelines when writing commit messages during code reviews.
2. Make and review only small pull requests – We use another developer to get a fresh pair of eyes on the code. A code review that goes for longer than 60 minutes and/or 300 lines of code, however, is tiring and defeat the purpose of using a fresh pair of eyes.
How do we know this? A study from SmartBear discovered that our brains can only process so much information, before the performance and the ability to find defects drops. This is why we recommend short but frequent code reviews.
3. Comment on the code and not the coder – Empathy goes a long way and is why it’s important to provide feedback on the code and not make it personal with snide comments. Doing so will ensure that the feedback on the code reviewed will be met with a positive response and encourage cleaner code in the future. This drives the collective code ownership that all organisations should strive for.
4. Describe a problem and give the solution – The code reviewers job is to find mistakes in the code and highlight it with suggestions on how to improve it. Personal preferences/opinions should play no part in this and is one reason why we insist code reviewers to provide feedback based on existing best practices and/or documentation.
5. Learn and share your knowledge – Code reviews as you might have guessed is a fantastic way to exchange knowledge between the committer and the reviewer. Such reviews, therefore, should be approached as an opportunity to learn something about the codebase, languages, frameworks and best practices. Doing so allows for the continuous development of the team, the code it creates and the company.
6. Comment only the code that was in the changelist – Commenting on every problem you see in the code and not just the ones in your scope is a good way to sour the relationship with the committer and reduce the velocity of your project. Commenting on the changes as they are being made is also a big nope as this can create an expanded changelist that includes many unrelated changes.
7. Approve code not when it’s perfect but when it’s perfectly acceptable – Being a perfectionist and criticizing every single line of code is not how you keep the developers motivated. Decide on what is really important and worth chasing as your task as the reviewer is to give the go-ahead for a working product. We recommend granting approval when remaining comments are for insignificant issues (like a typo) or are optional recommendations that you made.
8. Have a strong communication standard – A good strong communication strategy between the reviewer and the committer is important to ensuring the cleanliness of the code. We at Mood Up ensure this by asking both parties to confirm the receipt of a message with a 👍 or ✅. The committers are also encouraged to push back against any changes from the reviewers if they disagree with the changes requested. The reviewers should also give praise when the code is clean and congratulate on a job well done. Remember, positive reinforcement goes a long way.
To wrap this up, code reviews can be an exhaustive and sometimes frustrating process. The value it brings to the quality of code, however, is far superior and is why we integrate it into all the projects we work on. Doing so gives both the juniors and seniors of the company an opportunity to exchange knowledge and deliver a project that is bug-free to the client.