Explanation of High Debt Classes
What is a High Debt Class?
High Debt Classes are classes that have the most architectural complexity. These classes are graded on a scale of 1-10 and the top 20 classes with a score greater than 3 are listed as seen in the screenshot above in the vFunction Server UI.
The score is calculated by three metrics which are each independently given a score of 1-10 score too. These metrics are calculated by the combination of Dynamic and Static Analysis:
- Size is a measure of the number of Class Methods
- Dependencies is the number of Compile Time Dependencies the Class has
- Dependents is how many Methods use the Class based on the Dynamic Analysis
To see a list of High Debt Classes for an Application, take the following steps:
- Log into the vFunction Server UI
- Select Analysis in the top, center menu bar
- Select High Debt from the top of the right-hand sidebar
What is the Compile Time Dependencies Graph?
As seen in the graph above, the Compile Time Dependencies Graph can be very complex. In this example, the High Debt Class, TrialNotificationsSubmittedServiceImpl, has over a thousand Dependencies to other Classes. You can click on SHOW ALL DEPENDENCIES and COPY TO CLIPBOARD to copy all the Dependencies to a text file and get an initial understanding of the entanglement (which types of classes and which packages are involved) and how it might be addressed by manually refactoring the Class.
You can also click EXPLORE CALL TREE and see all the flows this Class participates in, to better understand its usage.
A good rule of thumb is that a Class with Debt Score greater than 4 is a candidate for code refactoring.
Clicking the OpenAI icon by the Class name enables you to further explore and understand ways to refactor the High Debt Class.
Managing High Debt Classes
The common options to deal with High Debt Classes are:
- Refactor the class. This option is the preferred one if this Class causes many Static Classes to be included in multiple Domains. After refactoring, you should do a new learning and update Viper to reflect the change in the analysis
- Add the Class to the Common Library and postpone the refactoring. Note that the downside of this option is that it may significantly increase the size of the Common Library and may result in Domain-specific Classes being included in the Common Library instead of being part of the Domain. However, this is the Best Practice if you decide to postpone the refactoring due to potential risk
- Ignore the class in case the class is going to be re-written. Note that, by doing this, you may remove too many relevant flows from the scope of the analysis