CTOs outlook on code review process and how to optimize it for your team?

Image result for Couple of professionals discussing code review process

CTOs outlook on code review process and how to optimize it for your team?

So, what exactly is a code review, or rather what it should be?

Definition: “Code review process is an orderly investigation of projects source code, intended to find plausible issues in it and estimate the code quality.”
The appropriate approach towards the code review process should be very focused and in line with all the project goals. Just like everything else, knowing why we do something, can be an excellent way to do that at its best. The whole exercise of reviewing a code should be to promote the environment of sharing responsibilities for improving the overall code quality.

Learning and adapting the best practices contributes to building and delivering quality software. After all, code quality impacts how dependable, impregnable, and reliable your project is. Providing a high-quality project is critical for all development teams. Especially with web technologies growing safety-critical, building a quality code becomes vital.

The code is classified as a Good-Code or Bad-Code. Good-code is of high quality, clean, well-written, and understandable. Whereas the Bad-code is not so much so, and it won’t last long, it’s bound to fail when it comes to continuous operations. Code quality for most projects is often somewhere in the middle. When a code is understandable, well-documented, and tested, it is considered excellent.
To get the code to be good, manual and functional testing isn’t enough, as it does not give any assurance about the program in the longer run. A review process always played a key role in our development process and even then based on the reviewer’s preferences, duplication and coding standards were easily overlooked or ignored during a manual review.

“A study on “Software Defect Origins and Removal Methods” found that individual programmers are less than 50% efficient at finding bugs in their software. And most forms of testing are only 35% efficient. Studies like these make it difficult to determine quality.”

Source

Common scenario in software companies for code review

There are many companies out there that have a code review process in play in their software development process. But most often as the CI/CD(Continuous Integration / Continues Deployment) environment leans towards progressive development, delivery becomes one of the critical aspects of the software development process. Due to which code review often takes the back seat. Ultimately, leading to a substantial technical debt that is going to affect the whole process and projects in the longer run. The ones that have a code review in place can take the various approaches so that the overall process may vary for every company.

For example:-

Some companies use ‘git’ extensively and have their pipeline set up in Master and Branch format so that every “pull request” incorporates a peer code review.
Some other companies, especially startups, don’t opt for a formal code review, and instead, they have a peer-to-peer discussion. Someone from the team casually looks at the code to make sure there’s nothing wrong with it.
Many companies use formal code reviews but only as a way of finding bugs that elude QA?

Source

All approaches have their merits and demerits, and it isn’t straightforward to measure the success rate of any code review process. It is most likely an ongoing exercise for a very long duration for every organization. Even we at Mindbowser have struggled with things like inappropriate comments made by the reviewer, time invested in the style, non-scalable architecture of the project, and general neglect towards the length and presentation of the code. The way we overcame these issues was by integrating an automated code review tool with the team’s existing process.
Before the code review process was pretty much manual. Our team used to write the code for a particular task and submit it for review. The reviewer reviewed all code that was up for review in branches of the assigned project. Only if the code passes the review successfully, was the code merged upstream or launched. But this was a very time-consuming and yet not a fail-proof method. Therefore, we built a solution around this exact issue of ours. “Codegrip”, which is an automated code review tool that allowed us to analyze the code based on particular language standards. Codegrip enabled us to add another layer for reviewing the code automatically at every commit.

This whole exercise drastically reduced the time required for code review and improved the overall code quality. Now on every pull-request, the reviewer reviews the analysis provided by Codegrip and the code written by the author. The code merges upstream only if it passes the review. Embedding automated code review tool, in our review process, allowed us to save time and prevent from populating the master line of the project. High quality should be the goal throughout the software development process.

What should be the expected mindset while setting up a code review process?

The first step should be the author reading their code even before a review. This notion allows the author to elucidate their code before giving it to the team. So, the reviewer finds fewer issues while reviewing his code. Often the author doesn’t have an observed and quantitative goal before or after the code is reviewed. Having this clear goal will increase accountability among the authors for their code. To set these goals, the best way to start is with proven matrices instead of defining something vague such as “fixing more bugs.”
All the standards that the author follows should be measurable. These observations good (best practices) or bad (mistakes made) can contribute to improving the code review process across the organizations. There are various benefits like better planning for enough time for a proper or slow review. So, the whole team is aligned on project objectives and the current state. All these observations, while conducting reviews on development artifacts like requirements, user stories, and design documents is a good way to ensure that your whole team understands the end goals of a project.
It is up to the manager to foster a positive attitude about finding defects. Code reviews offer an opportunity for all team members to correct bad habits to learn new tricks and expand capabilities.
A code review performed for functional verification is different from a code review conducted for quality purposes. A code review done for improving the quality should always have a designated automated code review process. It may be a pull-request on GitHub, a differential revision on, a crucible review on Atlassian, or any number of other review tools.

A good review is if the author improves the reviewed code and reviews it meticulously! He or she needs to be sure to read the code and concentrate on both the logic and its presentation, and not just skim through the code. It goes hand-in-hand with the idea for conceiving every single change made while reviewing the code, so the same mistakes are not made next time.
Reviewing the “Patch/Update/Enhancement” is also as important as the actual production code. It can be shocking just how often such patches and workarounds make it into production and become the correct logic for the project code rather than being replaced.

Reviewing the documentation/requirements, test cases, and built files are equally important. While reviewing these documents they should be.

Functional.
Clean and maintainable.
Optimized.

Reviewing can be intimidating, so it helps to remember that reviewers are not perfect! Issues may slip past the reviewer, and bugs may evade detection, performance flaws may make it to production. So adding multiple layers to a code review process is always a way to go.

We have always used code review as a team-building activity that has helped us find defects before launch and improve our overall software quality during launch. I would suggest doing a certain amount of code review each day, even if it’s not every line that’s fine.

A review process should always have breaks in between review sessions so that incessant code reviews don’t overwhelm the team. Implementing an automated code review tool for even greater efficiency and accuracy helps in optimizing the time teams spend on code reviews. We should always verify that defects are fixed. And lastly, having a checklist improves results for both authors and reviewers substantially. Using a list will remind the reviewer as well as the author, to take the time to look for something that might be missing during the code review, as well as helping to improve their coding skills.

Our observations while setting-up the code review process that works best for us

Implementing the automated code review tool in our existing manual code review process allowed us to enhance the overall process for software development in Mindbowser. It allowed us to plan time for all the projects in the pipeline. Having an automated code review tool helped our team to contribute and collaborate on smarter initiatives. Even the new members of the team started to learning much fasted then before and a drastic difference was noticed in the overall quality of code. Helping us to limit risk and costs simultaneously.