What is Code Inspection?
Code Inspection is the process of reviewing and improving the code before testing.
Both testing and inspection aim at improving the code, but they rely on 2 distinct concepts:
- Testing is dynamic and executes the software to check its functionalities.
(See also: Automated Testing with AscentialTest)
- Code inspection analyzes the source code based on a set of rules.
Manual, Automated or Continuous Inspection?
Several possible strategies for code inspection:
|Strategy||Description||Pros & Cons|
|Manual Code Review||Teammates review each other’s code to find and fix possible defects.||Better code Human costs > limited frequency|
|Peer Programming||2 programmers at 1 desk: one writes the code while the other reviews it.||Better code and Knowledge transfer.
Productivity can be challenging.
|Automated Inspection||Review performed by a machine.||No limitations in the frequency.
Requires Code Analysis Tools
|Continuous Code Inspection||Automatic reviews included in a Continuous Integration Workflow.||See below|
Why Implement Continuous Code Inspection?
Continuous Code Inspection is an essential part of the DevOps and Agile development process, where traditional code review is not enough.
Code inspection improves the overall code quality and security, while reducing remediation and maintenance costs by discovering potential defects at an early stage.
Each time a developer pushes his work into the CI/CD pipeline, the code is automatically scanned for defects. Common objectives for continuous inspection are:
- Detect and remove security vulnerabilities
- Comply with coding "grammar" standards
- Comply with code readability standards
- Architectural layering adherence
- Remove code duplicates
- Improve performance
- And more...
Types of Issues
|Bug||Flaw or mistake - other than syntax errors - that can break the application anytime. Fixing it is of highest priority.|
|Maintainability||This quality-related issue is not a bug. It is not technically incorrect and does not prevent the application from functioning. But it makes changes way more expensive and increases the probability of introducing new bugs.|
|Vulnerability||A flaw or weakness in code that could result in a security breach.|
|Security warning||A piece of code that may create a security breach, but must be manually examined to determine it.|
|Metric||Objective measurements of certain code properties or entities. Traditionally used for cost estimation, quality assurance, debugging, performance optimization, and task assignments.|
|Syntax error||Grammatical mistake in the syntax of a phrase that can prevent the code from compiling or executing. Fixing it is of the highest priority.|
Not all issues are critical. To help prioritize improvements, each issue comes with a severity level:
|Critical||Bug that will probably alter the proper functioning of the application and must be fixed as soon as possible.|
|Major||Security vulnerability, or bug that could possibly alter the proper functioning of the application. To be addressed as quickly as possible.|
|Minor||Quality defect that can significantly affect the developer's productivity.|
|Low||Quality defect that may slightly affect the developer's productivity.|
|Information||Metric or information about the code.|
How is the severity of an issue defined?
The severity level of an issue depends on its impact and probability.
High/low impact is evaluated with the following criteria:
- For bugs: can this problem break the application or corrupt the stored data?
- For vulnerabilities: if this breach were exploited, would it cause significant damage?
- For maintainability issues: could this issue cause a developer to introduce a bug?
|Inspection Rule||A coding practice that should be followed, to avoid generating bugs, vulnerabilities, or code quality issues.|
|Remediation Cost||The estimated time required to fix all bugs and security issues.|
|Technical Debt||The estimated time required to fix all Maintainability Issues|