Price sticky
image of code with search symbol

Building a better code review process

Building a better code review process


Complicated process but a mixed approach makes code review an indecisive process. Many reviewers are highly aware of practices that complete a code review as they have all the aspects on fingers using the code review checklist but we look into more excellent details on how to use those practices and in what order to build a better code review process than what you already employ.


Production Testing

Testing in a production environment means performing various tests in a live environment. It is a critical way to detect bugs in real-time or real-world scenarios. Take a detailed data set, something that applies to the software and run your code. You’ll find bugs that developers couldn’t because, for most time, developers use a minimal dataset just for the sake of convenience, which is fine for development purposes considering working from scratch and also time constraints.

Most developers make changes and deploy the software just to keep it up and running, but changes create bugs. This will result in a fatal error for the user and may result in loss of data.

The first thing you can do is manually view the code and figure out what realistic data would satisfy it. You’ll find an existing data set for most of the cases so it’ll fit right in. If not, create a realistic database of your own with proper naming conventions. Make sure you do not play with existing user data. Some developers using production testing, try load test on a live environment that will just break your software down. If you mean to do a test, do it when there is less load on the application. 

The production test is also essential to build a better code review process because of the lack of information at the developer’s disposal. Take a simple example of mock frames while designing UI/UX of a website or an app that has to contain some pictures. “Some” here is undefined and it will be impossible to create a perfect frame to fit every type of image possible, so without knowing what the actual data is, it becomes near impossible to implement.

Become User of Product

When you have a realistic data loaded up in your software, and it’s running in a live-like environment, its time to act like those people who will be using this product for a long time to come – the customers. Think like users of the product and deduce what job this software is fulfilling. 

When reviewing, don’t try to look directly at the code first. Instead, look at the log file that has errors and critical events to figure out what problems this code would have. 

Put yourself into the shoes of the ultimate user and improve your code. Just like a user, try finding bugs using edge cases and typical use cases – you’ll find something in one way or another. This also makes sure that you ignore a less technical debt also making your code clean, both top reasons to do code review process.

Calculated changes and risks

If you have made it this far and look to employ some changes, stop for a moment as think; Will this change do full justice to the code. Bringing changes in code can also introduce other bugs or smells in the system. So what to do in such a case? Even though we aim to implement changes that solve the problem and not adds to it, documentation of all such events is necessary. Every move you propose, tweak you make, or addition you do to code must be documented.

Documentation makes code review a robust process. Code review is a costly and time-consuming process and having to do it multiple times, is worth only if it means improvement. Look for the areas, your change may have brought some effect to code and make test cases to test the reliability.

Doing manual tests and then reviewing it at the same time is enough for the cause. The bottom line is that whatever the change is – self-contained or not, you must always scan for potential risks that it might bring to your software.

It can become challenging to evade risks with appropriate changes some times. At this point, you need to build a tradeoff between your options of change suggestions and the risks they impose. Competent reviewers make sure that the change they implement should have a lower radius of risk induction, and also has a calculated risk that your software can sustain.

Product over Code, Always

Code review is not about making the code better, but your product better. As it is always said, “Never compromise with the integrity of your product.” For all the manipulations you bring on to the code, answer this question every time – Will it be a positive change for my product? See how I focus on products and not code. Working on the code and not concentrating on the product will make sure that you are stuck doing code review for an extended period of time and stressing reliability vs. maintainability. 

You have to always work on customer needs and to make them happy, then work on the code from there. Changes you propose should solve a real problem for customers, while being robust. They should be an investment you make and not a massive debt that you need to care about in the future. Never implement changes that compromise with security and also that isn’t reversible. Lastly, all ramifications should be under budget and time so that the developer can apply and re-check it before deploying the software.


Wanted  Better Code Review Process ? Signup today and start checking your Code for Free

Liked what you read? Subscribe and get fresh updates.


    Post a Comment