Deutsch- Analysing an existing application if you join a project.
- Assessing the quality and maintainability of an application.
- Identifying soft spots in an application which could benefit the most from refactoring.
There are numerous reasons for wanting to size up the complexity of an application. In addition to general and language-specific tools provided by IDEs and applications such as SonarLint / SonarQube it can be useful to not only take framework specifics into account but to actually make use of them to get a better overall picture of the quality and complexity of an application.
Part of my work amounts to providing my clients with an appraisal as to the state their software currently is in and to point out potential avenues of improvement.
Often, Angular applications serve as a front-end in these cases and consequently account for a crucial part of the overall complexity.
In order to not just give an intuitive assessment and on the other hand to not have to individually and manually analyse each component of an Angular app each time (being a virtuous programmer, after all) I created a Ruby command-line script for analysing the complexity of Angular apps: https://github.com/BjoernKW/Miscellaneous/blob/master/measure_angular_component_complexity.rb
The idea behind that script is predicated on the assumption that the complexity of a code entity (class, component, service …) to a large degree is contingent on its dependencies.
The script takes a path with Angular source code as an argument (e.g. ./measure_angular_component_complexity.rb src/app) and recursively counts the different types of Angular dependencies (providers, imports and declarations) in the TestBed configurations of unit tests for Angular components (services, directives, pipes, guards …) on that path.
In order to achieve this the script goes through each file ending in .spec.ts and checks (using regular expressions) where the definitions for each type of Angular dependency begin and where they end, respectively.
This allows us to infer which dependencies are required for a component to compile. This in turn provides us with a rough indicator for the complexity of single components and an application as a whole. It’s not a particularly exact measure but it’s conducive to evaluating an application in order to subsequently be able to focus on the more complex components when it comes to a more detailed analysis and possible improvements.
The script assumes 1 provider / import / declaration entry per line, as for example defined by the Angular style guide. Counting multiple entries would be possible but would require more effort. Since IDEs allow you to easily reformat source code into conforming to 1 entry per line I limited the script to this simpler method.
Apart from individual dependencies by component the script also yields a total value for the application. This is based on tokens instead of types, i.e. if a particular dependency occurs in multiple components it’ll also be considered multiple times for calculating the total value.
A German language version of this article is available at Angular.DE: Abschätzung der Komplexität einer Angular Anwendung