[敏捷开发实践] 用Sonarqube评估系统中的 Technical Debt （技术债）

[敏捷开发实践] 用Sonarqube评估系统中的 Technical Debt （技术债）

Sonar中技术债务的计算基于SQALE（Software Quality Assessment based on Lifecycle Expectations，基于生命周期期望的软件质量评估）方法学。

Sonarqude Docs 7.9 https://docs.sonarqube.org/latest/user-guide/concepts/ 中描述的两个指标：

Technical Debt：The estimated time required to fix all Maintainability Issues / code smells

Code Smell：A maintainability-related issue in the code. Leaving it as-is means that at best maintainers will have a harder time than they should making changes to the code. At worst, they’ll be so confused by the state of the code that they’ll introduce additional errors as they make changes

有兴趣的读者可以看看这个文档：https://docs.sonarqube.org/latest/user-guide/metric-definitions/

Technical Debt ()
Effort to fix all Code Smells. The measure is stored in minutes in the database. An 8-hour day is assumed when values are shown in days.

Technical Debt on New Code ()
Effort to fix all Code Smells raised for the first time in the New Code period.

Technical Debt Ratio ()
Ratio between the cost to develop the software and the cost to fix it. The Technical Debt Ratio formula is:

Which can be restated as:

The value of the cost to develop a line of code is 0.06 days.

Technical Debt Ratio on New Code ()
Ratio between the cost to develop the code changed in the New Code period and the cost of the issues linked to it.

SonarQube基于单独的规则和问题实现了SQALE。那意味着，如果你想用SQALE管理你的技术债务，你首先需要公共的SonarQube存储库中那些规则的标记：

• 重复的代码块
• 失败的单元测试
• 不足的分支单元测试覆盖率
• 不足的注释密度
• 不足的单元测试行覆盖率
• 跳过单元测试

关于Technical Debt 基本概念的补充

Technical Debt 这个词现在在招聘的R&R描述中很流行。那么到底什么是 Technical Debt呢p>

简而言之，Technical Debt 就是：

The term “technical debt” was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.

“技术债务”一词是由Ward Cunningham创造的，用来描述软件组织在选择短期内有利的设计或构建方法时所承担的义务，但这会增加复杂性，并且从长期来看成本更高。

对于Technical Debt的不同解释

我们先看看https://www.techopedia.com/definition/27913/technical-debt 的说明

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

Technical debt is commonly associated with extreme programming, especially in the context of refactoring. That is, it implies that restructuring existing code (refactoring) is required as part of the development process. Under this line of thinking refactoring is not only a result of poorly written code, but is also done based on an evolving understanding of a problem and the best way to solve that problem.

Technical debt may also be known as design debt.

技术债务是编程中的一个概念，它反映了当使用短期内易于实现的代码而不是应用最佳的整体解决方案时所产生的额外开发工作。

技术债务通常与极限编程（XP，Extreme Programming）有关，特别是在重构环境中。也就是说，它意味着在开发过程中需要重组现有代码（重构）。在这种思路下，重构不仅是写得不好的代码的结果，而且是基于对问题不断发展的理解和解决问题的最佳方法来完成的。

技术债务也可以称为设计债务。

The term was coined by Ward Cunningham, a programmer who is also known for developing the first wiki.Technical debt is a metaphor that equates software development to financial debt. Imagine that you have a project that has two potential options. One is quick and easy but will require modification in the future. The other has a better design, but will take more time to implement. In development, releasing code as a quick and easy approach is like incurring debt – it comes with the obligation of interest, which, for technical debt, comes in the form of extra work in the future. Taking the time to refactor is equivalent to paying down principal. While this takes time in the short run, it also decreases future interest payments.

这个术语是由 Ward Cunningham 创造的，他也是开发第一个wiki的程序员。技术债务是一个比喻，它将软件开发等同于金融债务。假设您有一个项目有两个潜在的选项：一个是快速和容易，但在未来将需要修改。另一个有更好的设计，但需要更多的时间来实现。在开发过程中，将代码作为一种快速而简单的方法发布就像招致债务一样——它伴随着利息义务，对于技术债务来说，利息义务是以未来额外工作的形式出现的。花时间重构相当于支付本金。虽然这在短期内需要时间，但也会减少未来的利息支付。

Ward Cunningham describes this concept in 1992 as follows:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

The concept does not mean that debt should never be incurred. Just as leverage can help a company when used correctly, a quick solution can mean a faster time to market in software development. In addition, technical debt is not just poor code. Bad code is bad code, and technical debt can result from the work of good programmers under unrealistic project constraints.

Ward Cunningham 在1992年是的描述如下：

“第一次交付代码就像负债一样。一点点的债务可以加速发展，只要它能迅速地用重写来偿还。对象使此事务的成本可以接受。当债务没有偿还时，危险就出现了。花在不太正确的代码上的每一分钟都算作债务的利息。整个工程组织可以在未合并的实现、面向对象或其他方面的债务负担下停滞不前。”

这个概念并不意味着永远不应该发生债务。正如杠杆在正确使用时可以帮助公司一样，快速解决方案意味着在软件开发中更快地上市。此外，技术债务不仅仅是糟糕的代码。坏代码就是坏代码，在不现实的项目约束下，好的程序员的工作会导致技术债务。

再来看看 Martin Fowler关于技术债的观点 https://martinfowler.com/bliki/TechnicalDebt.html

Thinking of this as paying interest versus paying of principal can help decide which cruft to tackle. If I have a terrible area of the code base, one that’s a nightmare to change, it’s not a problem if I don’t have to modify it. I only trigger an interest payment when I have to work with that part of the software (this is a place where the metaphor breaks down, since financial interest payments are triggered by the passage of time). So crufty but stable areas of code can be left alone. In contrast, areas of high activity need a zero-tolerance attitude to cruft, because the interest payments are cripplingly high. This is especially important since cruft accumulates where developers make changes without paying attention to internal quality – the more changes, the greater risk of cruft building up.

The metaphor of debt is sometimes used to justify neglecting internal quality. The argument is that it takes time and effort to stop cruft from building up. If there new features that are needed urgently, then perhaps it’s best to take on the debt, accepting that this debt will have to be managed in the future.

The danger here is that most of the time this analysis isn’t done well. Cruft has a quick impact, slowing down the very new features that are needed quickly. Teams who do this end up maxing out all their credit cards, but still delivering later than they would have done had they put the effort into higher internal quality. Here the metaphor often leads people astray, as the dynamics don’t really match those for financial loans. Taking on debt to speed delivery only works if you stay below the design payoff line of the DesignStaminaHypothesis, and teams hit that line in weeks rather than months.

把这看作是支付利息而不是支付本金有助于决定要解决的问题。如果我有一个糟糕的代码库区域，这是一个噩梦要改变，这不是一个问题，如果我不需要修改它。只有当我必须使用软件的那一部分时，我才会触发利息支付（这是一个比喻失效的地方，因为金融利息支付是由时间的推移触发的）。因此，代码的简单但稳定的区域可以单独使用。相比之下，高活动地区需要对原油采取零容忍态度，因为利息支付非常高。这一点尤其重要，因为在开发人员不关注内部质量而进行更改的情况下，cruft会积累更多的更改，从而增加了cruft积累的风险。

债务的比喻有时被用来证明忽视内部质量是正当的。有人认为，阻止原油积聚需要时间和精力。如果有迫切需要的新功能，那么最好承担债务，接受这种债务在未来必须得到管理。

这里的危险在于，大多数时候这种分析都做得不好。Cruft的影响很快，减缓了快速需要的新功能。这样做的团队最终会最大限度地利用他们所有的信用卡，但如果他们将努力投入到更高的内部质量中，交付的时间仍然会比他们本应该做的晚。在这里，这个比喻常常导致人们误入歧途，因为这种动态与金融贷款的动态并不匹配。承担债务以加速交付只有当你停留在designstamina假设的设计回 线以下，并且团队在数周而不是数月内达到这条线时才有效。