Calculating Design Violations Technical Debt with SonarQube

Question

I was wondering if it is possible with the latest version of Sonar or through some plugin calculate the techical debt of an architectural violation (from a java project) like: "'X' class should be in com.domain.classes package" or "the class 'X' must extend the class 'Y' "? Or "The 'X' class must have a 'public static Y someAttribute' attribute"?

If there is no plugin for this, there is how to develop a plugin to automate this? I have read the documentation for the Java API, REST, how to develop a plugin and tried to code it, but have not found a way to do it.

Answer 1

The only way to do this is through the Commercial SQALE plugin, inserting manually the remediation costs of an extended Architectural Constraint, XPath, PMD and another similar rules.

Sonarqube answer: http://sonarqube.15.x6.nabble.com/Calculating-Design-Violations-Technical-Debt-with-SonarQube-td5022251.html

Answer 2

On possible route is to use the PMD code checker. You can add your own custom rules to PMD, and there is a PMD plugin for Sonar.

---

But in that case, Sonar can calculate the debt (through SQALE or another plugin) for me? In another case, how i can calculate the debt?

I think you misunderstand the "technical debt" term. Here is how Wikipedia describes it:

Technical debt (also known as design debt[citation needed] or code debt) is a neologistic metaphor referring to the eventual consequences of poor software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy.

The key thing to note is that technical debt is a metaphor.

So, for example, PMD could tell you how many times your code violates certain rules, but it cannot tell you how much work it would be to fix them, or how much extra work in the future would be incurred because you didn't fix it now.

Basically, you cannot measure technical debt because a true measure of technical debt requires knowing what is going to happen in the future. Also read this: https://softwareengineering.stackexchange.com/questions/167080/how-is-technical-debt-best-measured-what-metrics-are-most-useful