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:
|
Phase
|
Cost to
Remediate
|
|
Requirements
|
1x
|
|
Design
|
5x - 7x
|
|
Build
|
10x - 26x
|
|
Testing
|
50x - 177x
|
|
Production
|
100x - 1000x
|
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:
- 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.
- Code Reviewer opens up the code and begins to check the code:
- Does the code do what it is actually supposed to do based on the requirements/user stories?
- Looking for obvious defects in the code that might produce errant results.
- Does the code adhere to the established coding guidelines that the team uses (there are tools that can automate this)
- Code Formatting
- Variable Naming Conventions
- Is there Automated Test Coverage for the code being reviewed?
- Have the tests been written in a way that is easily understood and provides clear results?
- Have the tests been written to provide red route/green route testing – is the sample of tests broad enough to fully test the functionality?
- Does the code adhere to the security/regulatory guidelines used by the team (OWASP for web)?
- Does the code fit into the overall architecture of the application?
- Does the code introduce potential performance issues that need to be addressed.
- Is the code in the right place, are the services and methods grouped into the right places to easily be found by other developers?
- Did the code introduce ‘duplicate functionality’ that should be removed?
- Has the code been written in a way that is easily understood?
- When the new code fails, do the exception messages provide clear direction on what failed and why?
- Reviewing complex algorithms to see if they can be simplified.
- Identifying chunks of code that are not needed anymore that should be removed.
- Code Reviewer identifies recommended changes to the code that was submitted and documents the changes for the Code Submitter.
- Code Reviewer discusses the recommended changes to the code with the Code Submitter in a respectful manner.
- Code Submitter makes agreed upon changes to the Code.
- Code Submitter circles back to Step 1.
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.
If you'd like more information on my background: LinkedIn Profile
No comments:
Post a Comment