The Three R's of Code Review Process

“Code failed”, “Code quality isn’t good enough”, “Fix the code” - Every software development team would’ve heard this many times. Why is the code getting blamed first hand? Why, when a defect is raised, code is getting questioned? Simple – Code is the one that does the things. Without code, your system does not exist and it does not function. So, eventually any software issues stare first at code quality. Code is the super hero, at the same the prime suspect (Though tt may not necessarily be the villain) in every incident.

So, code essentially is the entity that needs more caress from the people concerned. This leads to the demand for a robust process to ensure code quality before getting it on to the end customer. This generally we call the “Code Review” process.

Every Engineering Team in any organization would have established their own standards or guidelines and a process around the code. Here, I would like to emphasize the importance of three key steps in any code review process, which is the three R's or the Read (Is to know what is it doing) -Review (Is to understand how is it done) -Refine (Is to see if there is a better way to do it) steps.

Read

I have seen a false belief that many developers possess, that the code is a write-only entity. Please get away with this. Code should be read, repeatedly.

Why? You may have good amount of documentation; you may have system experts around you but does it educate you completely about the functioning of the system. Probably there could be a delta! But, code is the one entity that sincerely tells you “this is what I am doing”. So, to understand the shortcomings of the system, reading and understanding the code is super important.

We keep adding or deleting code as we keep developing new functionalities. Every single time we do this, read the code and assess the implications very well. The code starts staining when you keep it longer without tuning it.

Who should read the code? Everyone who is concerned with it – the developer who writes it, co-developers, senior leads and managers, architects, everyone!

Well, how do you read? Do we catch a route completely by looking at Google Maps? Perhaps you get to know how to traverse to destination. But to master the route you have only one choice, which is to take a ride! Same is the case with code – just by reading you may not master it, instead take it on debug and understand all its paths, failure points and shortcomings. When you start doing so, you are taken to the next step of this process – Review.

Review

Review is misunderstood by many, to be a process where the code is inspected against a set of standards. It should be more than that, and in fact verification of code against a certain set of rules shouldn’t really be a human act. All such tasks to verify patterns, rules and guidelines can probably be delegated to automation tools, and the deep functional aspects can be delegated to the more powerful human time.

When you do the code review, the image of the developer who wrote that should just not be blurred but fully erased. Only the code should remain in the background.

Review of the code shall be multi layered.

• Every developer himself/herself should review the code written by them. Having a second look after it is written would always pave way for doing things better.
• Co developers should review as well. Code is not a product of a developer alone but a product from a developer community. So everyone should have their eye on it.
• Leads, managers and architects as well should review the code. They see it from a broader perspective. They apply their experience and can offer their caress to the code.

You can engage team collectively in reviews and that helps better learning within. Or, in case of very specific coaching needed for certain developers you can get into one-on-one review discussions and the observations can be socialized later.

Refine

Once the review is done, you have a set of observations. Get these observations evaluated thoroughly and arrive at possible refined solutions. As relevant, have them discussed in person or in groups and as needed, even brainstorm it and refine further – It is not my code or your code, it is our code.

• Refining the code may have huge benefits in terms of both Functional and Non-Functional Requirements
• It may still help identify gaps from established guidelines
• Potential performance boost to the system
• Better utilization of system resources, real estate on the user screens etc
• Better user experience in terms of ease of navigation, messaging back etc
• Adding business value to the system in hand
• Handling any compatibility issues or cross functional dependencies etc
• Does the code effectively communicate problems it faces, to make troubleshooting easy?
• Many more .... !!!

Once possible refinement is done, please don't assume it ends there!!!

Please also remember, once you have refined, you not only have a refined code but also have some more learnings to educate the team. So, have the new learnings documented and socialized as well.  

Having these effectively done ensures your code stays clean and effective. This should be a repeatable process to make sure the code does not stain.

{An elaborated view of how I see the Refine process shall be presented in an upcoming article}