The only constant is change. In 2015, we did not have a formal code review process. However in 2016, we decided to change how we build software. Reliable software. Now we have introduced a formal code review process. In a nutshell, we have to pull down the subversion branch or branches and review each revision. The review process also involves compiling code, running unit tests, and trying to break the code. With this in mind, I wanted to share the benefits of performing code reviews.
Reduce Bugs
While performing code reviews for a year, we have concluded that bugs have been reduced significantly. The developer looking at the code changes is wearing a quality analyst hat during this time. If the code review is done correctly, he or she should find bugs. Sometimes it is a simple misspelled word, other times code won’t compile, or a unit tests fails. Many studies have found that finding bugs during development is less expensive than finding the same bug in production. If we encounter a bug six months from now, the developer will have to spend more time understanding the bug and trying to come up with a feasible solution.
Get Familiar with Code
Many times we have to review code that we have never seen. This is a great opportunity to learn about it. Sit down with the developer and ask questions. In our team, we have a developer who is in charge of applications written with PowerBuilder. He asked me to review his code and we sat down together to complete this important step in our development process. Most of our applications are written with .Net but having the knowledge of the PowerBuilder applications allow us to get familiar with all of our applications. Don’t be afraid to learn something new.
Learn New Tips and Tricks
Recently we had the opportunity to use PostgreSQL within a .Net application. Our team spent a lot time looking at syntax because it was our first time using PostgreSQL. One of the things we had to figure out was how to set the primary key. At the beginning we created sequences and it was a 2 step process. However when I had to do a peer review, I did not see a sequence created but a serial. Using serial was much simpler and the team liked the simplicity of using serial vs sequence. We also learn new tips when reviewing code together. Developer and reviewer sitting next to each other discussing code changes. Many times we picked keyboard shortcuts and tricks that improved how we built software.
Keep Code Consistent
If you look at our code base, it looks like the same developer wrote it. It contains the same architecture. It uses the same naming convention. Having a formal peer review process has allowed our team to keep the code consistent. This also helps new developers jump right into our code and be productive. The new developer does not have to learn 3 or 4 different architectures.
There are many benefits in doing code reviews. In our experience, we have seen the number of bugs reduced because bugs were found during development. Our developers were able to fix the bugs while we were in development. We have also be able to keep a consistent code base with the same architecture.