Coupling analysis
In large codebases with multiple developers one of the most important factors contributing to technical debt are the hidden dependencies between separate subsystems that from a design standpoint were meant to be unrelated. That is even when the design begins with the aim to keep individual modules decoupled, yet implicit couplings may form in time between components of each module due to a number of different reasons. The stronger these couplings grow, the more rigid the design of your system becomes, and the harder it gets to extend its features. Therefore it is important to be able to detect these couplings early on and do something about it before the refactoring work turns into an overwhelming effort.
Coupling between different parts of a system may also manifest itself at a higher architectural level or by affecting communication and expertise dependendencies between different teams and/or developers. This and other aspects of the problem are described in System Analysis and Social Analysis
When it's not obvious which modules to target with a temporal coupling analysis, we can use the sum of coupling analysis to try identify modules with high degree of coupling that are also architecturaly significant. The sum of coupling value is derived by calculating how often, in a given period of time, a module changes together with other modules. The files with the most frequent couplings/shared commits are good candidates to start a temporal coupling investigation.
$ gulp sum-of-coupling-analysis [--dateFrom=<dateFrom>] [--dateTo=<dateTo>]The sum of coupling is a simple report ordered by modules with the higher coupling. A file path filter allows to display the results for only a part of the files in the repository.
This task targets a particular file/module in the codebase and specific time periods. The resulting report is a list of files/modules that are potentially coupled with the original file. The coupling degree between two files is determined based on the number of shared commits within the given period.
$ gulp temporal-coupling-analysis --targetFile <targetFile> [--dateFrom=<dateFrom>] [--dateTo=<dateTo>] [--timeSplit=<timeSplit>]- The targetFile parameter identifies the file under investigation. The path must be relative to the root of the repository and not an absolute path..
- The timeSplit parameter is used to split the original time interval of the analysis in periods of known duration (e.g. 2 weeks, one month etc.). For more details refer to Tasks parameters.
The results of the temporal coupling analysis are again displayed through an interactive enclosure diagram. The node filled with blue colour is the target file/module of the analysis, while the other displayed circles (filled with red) are the coupled files. The darker the colour the higher the degree of coupling. The diagram presents different views corresponding to each analysed time period. Switching between the periods/views gives an initial idea of how the coupling of the target module changes in time and what other parts of the codebase are affected.
Hovering over any particular node reveals more details about the coupled entity. In particular the coupling degree is indicative of the strength of the coupling with respect to the other files. Also of interest are churn metrics like added and deleted lines of code: combining the information of how files grow or reduce in size together with how they are coupled can offer important insights on the kind of dependency and whether it represents a serious problem or not.
