Code Review | Foolproof Your Software Quality

Code reviews can be tedious and if the code is somebody else’s then some frustration is justified. However, code reviews do save a lot of time and keep breaking errors in check. 

Based on the scale of your project you can either go with peer review or with group review. When you’re confident about your code and are in a time crunch, you can choose to get your colleague to review your code. This way, you get an error-free code that can be pushed for production. On the other hand, if the project scale and team size are larger, you can opt for a group review. Let’s explore both these options – 

What is a Peer Code Review?

Simply put, when you ask one of your teammates to see if there are any mistakes or areas of improvement in your code.

The Process

Typically, when the code is complete and ready for review, the developer creates a request to get it reviewed and forward it for release once approved. The assigned reviewers then approve or reject the pull request depending on the quality of the code. If approved, it implies that the code is ready to be merged in the release branch. Just to an additional layer of assurance 

To ensure the highest code quality and keep a check on code churn, practice heads like development lead and engineering head are also added default reviewers. They are notified via emails about the requests along with developers that are doing the review. These reviews are dynamic and are done as and when the pull requests are created. 

What to Look for During the Review

Even though there are multiple sets of eyes involved, there’s a lot that can still go wrong with peer reviews, if not taken seriously. Blanket approvals will only set you back further. Different teammates might have different standards of code quality, in that case, a checklist can help people align.

Peer-review Checklist 

This checklist can help the reviewers prioritize what matters and find out defects before the code goes for production. 

What is a Team Code Review?

It’s like peer review but more people are brought in for this and review the code as a group. The motive here is to bring different sets of people with different expertise onboard to test the overall feasibility of the code. Think Developers, Testers, Architects, and Managers gathering weekly for code review.

The Process

Since a lot many people are involved in a group review, it calls for a slightly different approach than the one used in peer review. 

• The developer presents the user story to the entire team. 
• Review of the design as per the user story implementation.
• Then the code is discussed and reviewed by the review group.
• Test cases are compared with the business rules implemented in a user story.
• Code walkthrough is done to get the logic across to every individual, sanitizing the code in the process
• SQE group presents the test cases based on the user story.
• Database dependencies like table schema, initial data scripts, data upgrade scripts are then reviewed by the DB team.
• The Release Engineering team is then brought in to discuss and review the dependencies on the deployment scripts.
• The performance team then gets inputs and benchmarks performance for the user story.

Who looks for what during these reviews?

Developers will use other stories as a basis and compare from a coding perspective to see if there are any dependencies. 

Testers will look for business rules that are part of the test cases and try to circle out the ones that are not if implemented. 

The architect ensures that everything is as planned and according to the initial blueprint. And if all the design principles and best practices are employed to ensure software quality. 

Teams like Database, Release Engineering, and Performance Engineering will look for dependencies in their area of expertise.

Why Team Code Review

• It helps break the practice and mentality of working in silos which prevents interaction across teams. 
• It’s easier to spot errors with multiple eyes on your code
• Testers help identify functional gaps before it’s too late
• The architect will keep shortcuts in check
• The shared services team will get inputs for executing the corresponding steps in their area of expertise.

Code reviews can seem like a marginal change to your process but the results are quite significant. One of the most overseen benefits of these group code reviews is to bring teams together. And when they are working as a whole instead of domain-made silos, great products emerge. It also serves as a learning opportunity for a lot of people. People who come from different domains and junior resources are just starting. 

And of course, this bi-directional learning process will help keep your code symmetrical across systems while keeping it maintainable, scalable, readable, and of the best quality.

About Galaxy Weblinks

We specialize in delivering end-to-end software design & development services and have hands-on experience with large, medium, and startup business development requirements. Our engineers also help in improving security, reliability, and features to make sure your business application scale and remains secure.