Code Reviews - A Must For Any Team!

As professional coders, we should be concerned about the cost to remediate ‘bad requirements’ or ‘defects introduced into the code’ thru the development process. Over the years studies have shown that there is a significant increase in cost to remediate these code issues the deeper into the development lifecycle that you go. One of the most recent published studies completed by NASA broke it down as follows:

In other words, if a bad requirement is not caught before design, by the time it makes it all the way into the production environment, there is a cost of 100x to 1000x the original cost to remediate the requirement. Yikes! Now, if a developer makes an error in building the feature/function described in the requirements or introduces a defect into the code unrelated to the feature/function being built, the cost to remediate that when found in production would be 10x to 100x if it was caught and remediated during the build process.

From a pride perspective, no coder wants to be seen as the one that introduced the bad code or broke current functionality. Beyond the pride factor, though, there are real hard costs being spent by organizations to remediate these issues, as well as the reputational impact with customers.

There are things that developers can do to lower the risk of introducing defects into the code base and to limit the exposure of the additional costs needed to remediate these bugs. Code Reviews are a proven paradigm that developers can use to catch these issues early and to remediate them during the build process.

Code Reviews: The intentional and systemic check of code by other developers to identify and remediate mistakes or security threats. The practice has repeatedly shown that it can accelerate and streamline the software development process and reduce the number of defects that reach production. In its simplest terms, a code review simply means that the person developing the code shares that code with other developers who review the code to:

• Ensure that team coding standards are followed
• Look for errors that can be remediated.
• Look for ways to ensure the integrity and security stance of the application
• Look for ways to simplify algorithms
• Look for ways to remove code that is not needed

As much as we like to think we aren’t the ones that introduce defects into the code base, we are humans and therefore the code will contain errors – those errors may be small, or they could be significant show stoppers. As professionals, we should acknowledge that fact and look for ways to mitigate these issues early. And that, my friends, is why Code Reviews became a thing!

When Code Reviews are done properly, they will address all of the above items, they will reduce time needed in later stages of the lifecycle, they will deliver hardened code into the production environment, they will reduce ongoing maintenance costs, they will foster communications within the development team, they will provide a means for more experienced engineers to mentor those engineers not as familiar with the code and they will ultimately increase the confidence and trust of the customers using the application. With all the positive impacts that code reviews can have for the developer, the team, the organization and our customers, why wouldn’t we use this well-defined paradigm to improve the quality of what we deliver downstream and ultimately to our customers.

Let’s quick review how this process looks:

1. Code Submitter (the software engineer changing the code) checks the code into the repository and makes the Code Reviewer(s) aware of the code requesting a review take place.
2. Code Reviewer opens up the code and begins to check the code:
3. Does the code do what it is actually supposed to do based on the requirements/user stories?
4. Looking for obvious defects in the code that might produce errant results.
5. Does the code adhere to the established coding guidelines that the team uses (there are tools that can automate this)
6. Code Formatting
7. Variable Naming Conventions
8. Is there Automated Test Coverage for the code being reviewed?
9. Have the tests been written in a way that is easily understood and provides clear results?
10. Have the tests been written to provide red route/green route testing – is the sample of tests broad enough to fully test the functionality?
11. Does the code adhere to the security/regulatory guidelines used by the team (OWASP for web)?
12. Does the code fit into the overall architecture of the application?
13. Does the code introduce potential performance issues that need to be addressed.
14. Is the code in the right place, are the services and methods grouped into the right places to easily be found by other developers?
15. Did the code introduce ‘duplicate functionality’ that should be removed?
16. Has the code been written in a way that is easily understood?
17. When the new code fails, do the exception messages provide clear direction on what failed and why?
18. Reviewing complex algorithms to see if they can be simplified.
19. Identifying chunks of code that are not needed anymore that should be removed.
20. Code Reviewer identifies recommended changes to the code that was submitted and documents the changes for the Code Submitter.
21. Code Reviewer discusses the recommended changes to the code with the Code Submitter in a respectful manner.
22. Code Submitter makes agreed upon changes to the Code.
23. Code Submitter circles back to Step 1.

That’s a lot of stuff! But the benefits are huge if done correctly. The beauty, I’ve seen interns and new engineers perform successful code reviews and give feedback to seasoned engineers, just as I’ve seen our most experienced engineers give guidance to our newest team members. This process in itself fosters communication within the team and opens up doors that allows the team as a whole to raise the bar and create high quality code. This becomes the expectation within the team, nobody wants to be seen as the coder that introduced a bug, they all want to be seen as experts in their chosen profession. Additionally, it gets developers talking to each other and opens up opportunities not seen in the code review process where they will begin to discuss challenges in real-time as the code is being created and not wait for the code review process to catch the issue.

I’m not saying that this will catch everything, again, we’re all human. But by using code reviews properly, we enhance our ability to catch issues early and remediate them before they impact our user community and potentially damage our reputation.

via: https://anidea4today.blogspot.com/