CodeScene is the world’s first behavioral code analysis platform. As such, there are some new concepts that you might not be familiar with from other tools. The purpose of this document is to explain the terminology.
Domain: Building maintainable Software Systems and efficient Teams¶
CodeScene’s mission is to turn code analysis data into actionable information for the whole organization. We see the largest value add in working as a communication bridge between the engineering organization and management. As such, there are some general terms that we want to cover in the context of the CodeScene platform.
Behavioral Code Analysis¶
The main difference between CodeScene’s behavioral code analysis and traditional code scanning techniques is that static analysis works on a snapshot of the codebase while CodeScene considers the temporal dimension and evolution of the whole system in the context of the development work. That is, while the code is important, it’s even more important to uncover how it evolves and where it’s heading.
Another key distinction between behavioral code analysis and traditional techniques, is that a behavioral code analysis focuses on the development organization. This enables powerful organizational and social analyses.
Read More: How it works.
Technical debt is a metaphor where – just like in finance– debt incurs interest payments. This means that technical debt makes code more expensive to maintain than it has to be. This has a direct impact on business. The typical development organization can increase their feature delivery efficiency by at least 25% by managing technical debt.
Read More: Technical debt knowledge bank at codescene.com.
While the technical solution is important, managing the people side of software is vital too. System Mastery means that everyone involved with the system maintains knowledge of how the system works. An organization loses System Mastery when there’s a high turn around on staff or due to increasing complexity of the system.
Code complexity refers to how challenging the code is for a human to understand. As humans, we can only keep a finite amount of information in our head and reason effectively about it. Once a piece of code grows in size (many lines of code) or conditions (logic like if-else chains), our working memory can no longer keep up and we start to make mistakes. Code Complexity is addressed via refactoring.
Read More: Code complexity patterns.
Refactoring is the process of improving existing code without changing its behavior. Refactorings are typically small and done in increments; we start with some overly complex code and simplify it.
The most common refactorings are to extract a method, encapsulate a complex conditional, or renaming a variable. Many refactorings are automated via IDEs. An effective refactoring process requires good test automation as a safety-net to ensure we’re not changing the external behavior of the code.
General: Projects and Analyses¶
A CodeScene project refers to one or more Git repositories together with their analysis configuration. The project is an organizatory construct used to trigger analyses. We recommend to define one CodeScene project per product line, no matter how many Git repositories you use to represent the codebase.
A CodeScene analysis of a specific project at a point in time. We recommend to schedule a daily CodeScene analysis so that your dashboards are always up to date.
A quick analysis of work in progress. A Delta Analysis analyses the changed code with reference to the target branch (e.g. develop, main).
CodeScene supports out-of-the-box integrations with GitHub, BitBucket, Azure DevOps or GitLab via our PR Integration.
Read More: PR Integration with CodeScene’s Delta Analysis.
CodeScene automates a Delta Analysis via webhooks to Pull Requests. This integration is used as input to code reviews and/or as a quality gate (e.g. fix the code health degradations before merge).
Read More: Integrate CodeScene with Pull Requests.
Recommended Review Level¶
As part of a Delta Analysis, CodeScene recommends a review level. The recommended review level is relative to the risk profile for your codebase. The review level is intended to let your team prioritize code reviews that have an increased delivery risks.
Under the hood, CodeScene calculates a unique risk profile for your codebase based on how the system has evolved and what a typical change set looks like. This risk profile is a combination of technical and social metrics. The technical metrics relate to the depth and diffusion of the change – the more changes and the more widespread, the higher the risk.
Read More: PR Integration with CodeScene’s Delta Analysis.
Technical Analyses: Hotspots, Code Health, and Change Coupling¶
Hotspots identify the code with the highest development activity. As such, hotspots point to modules that are likely to have a high business impact and affect maintenance costs and the effort to implement new features. Hotspots are calculated on three levels:
file level hotspots,
architectural hotspots as defined by the configured architectual components, and
function/method level hotspots via CodeScene’s X-Ray analysis.
Note that hotspots don’t imply a quality problem on their own; hotspots are about _relevance_ to be able to reason about code quality and impact within a context. This means that hotspots need to be combined with the code health measure.
Read more: Hotspots.
The Code Health metrics is based on patterns known to correlate with increased maintenance costs. Patterns that make the code harder to understand and, hence, increase the risk of change and make the module more expensive to evolve.
The Code Health score goes from 10 (healthy code that relatively easy to understand and evolve) down to 1, which indicates code with severe quality issues. The score is calculated from a combination of both properties of the code as well as organizational factors. In total, CodeScene calculates 25-30 factors depending on programming language.
Read more: Code Health – How easy is your code to maintain and evolve?.
X-Ray is an analysis that calculates Hotstpots on the function/method level. The resulting function-level hotspots serve as a prioritized list on where to pay down any identified technical debt.
Read more: X-Ray.
Change Coupling means that two (or more) modules change together over time. CodeScene provides several different metrics for change coupling. The tool considers two modules coupled in time:
if they are modified in the same commit, or
if they are modified by the same programmer within a specific period of time, or
if they refer to the same Ticket ID in their commit messages.
Change Coupling is calculated at three levels: architectural, file, and function level.
Read more: Change Coupling: Visualize Logical Dependencies.