转载

技术债务量化的局限：你依赖这些数值吗？

下面是发生在会议午餐期间的一个对话片段：

参与者A：接下来你要参加哪一场？

参与者B：我在考虑参加这个关于技术债务的演讲。

参与者A：噢，技术债务……我们已经使用工具“XYZ”精确地量化了技术债务的量，用偿还债务所需要的工作量来表示，单位为人力小时。它甚至为我们提供了漂亮的图表和可视界面。因此，我不需要参加这个演讲了！

这段对话在我的脑海中引发了一个有趣的问题：在成本和工作量方面，借助当前可用的技术债务工具，能准确地知道软件有多少技术债务吗？这样的一种量化可能在所有方面准确而完整吗？

当前可用的技术债务量化工具和框架所提供的量化数据是不准确、不完整的。为什么呢？考虑下以下原因：

缺乏一致的技术债务量化维度 ：技术债务有各种维度，包括代码债务、设计债务、架构债务、文档债务和测试债务。技术债务并没有一个普遍接受的范围定义。例如，许多人认为，已知的缺陷也构成技术债务。当前这套技术债务量化工具并没有明确地描述它们所采用的技术债务的维度范围。这会导致一种误解：使用工具的用户会认为，工具得出的结论是完整而准确的，因此，除了工具所提供的信息外，他没有必要为技术债务的维度操心。
对各种技术债务维度的识别和量化支持较差 ：当前可用的技术债务量化工具仅仅关注几个维度，比如代码债务和一定程度的设计债务和测试债务。对于同其它维度相关的问题，比如架构债务或文档债务，这类工具并没有提供全面的检测支持。实际上，对于所支持的维度，其全面性也是有问题的。例如，这样的工具识别和报告了多少设计债务问题（或设计味道）？虽然这样的工具支持一套设计规则（可以检测设计味道），但这样的规则也屈指可数。而且，处理由底层分析工具生成的主动错误信息（即错误警报）本身就很困难。
笼统地绝对化 ：技术债务量化工具将识别出的问题转换成修复它们所需要的绝对工作量。修复技术债务问题（尤其是设计和架构相关的问题）所需的工作量会随问题上下文（比如，严重性、范围、平台、技能）的变化而变化。这样一来，笼统地绝对化所产生的估计值与实际情况远不相符。因此，这样的量化最多只能是一种近似，而且必须这样看待它（而不是作为什么板上钉钉的事情）。
缺少利息部分 ：任何类型的债务都有两个部分：本金和利息。当前可用的技术债务量化工具都关注（和计算）与技术债务问题相关的本金，而忽视了利息部分。这使得量化并不可信。一些研究者（比如Ariadi Nugroho等人[1]和Vallary Singh等人[2]）提出了方法，用于计算本金随着时间推移所累计产生的利息。然而，当前的工具并没有包含同他们的技术债务计算相同的方式。利息部分——尤其是关系到增加了理解难度——非常难以（如果可能的话）准确地量化。

让我们讨论两个例子，说明一下为什么当前可用的技术债务量化工具不完整、不准确：

例子1 ：考虑下这样一种情况，有一个大型的企业软件产品正处于维护阶段。软件的原始设计严格遵循分层设计风格（即每一层都只能访问其下面直接相邻的层）。一个架构师最近加入了该项目，他借助架构分析工具在整个代码中识别出了数以百计的分层违规之处。这些债务问题包括“跳跃调用”（即一个层直接访问了一个更低的层，而不是通过其下面直接相邻的层）和“回调”（即一个层调用了它上面的层，这在分层设计风格中是被禁止的）。他们的团队已经使用技术债务量化工具作为质量监控仪表盘的一部分。然而，这些技术债务量化工具并没有覆盖这个架构债务维度，因此，工具所展示的技术债务情况有误导性。
例子2：考虑下量化一个订单处理系统的技术债务。假如在之前的其中一次发布中，为了赶在最后发布期限之前发布，作为一个捷径，与税务相关而与订单处理无关的复杂计算被添加到一个现有的Order类中，并计划稍后修复。这在技术债务中属于“慎重和故意”[3]的情况。现在，代码分析人员通常不会发现这个问题。设计分析人员很可能会发现这个问题——如果该类内聚性特别低（由于与税务相关但与Order类无关的职责被添加到这个类中）。例如，Designite[6]会将这样一个设计味道识别为“多元抽象（Multifaceted Abstraction）”。需要重点注意的是，只有你所使用的技术债务量化工具直接或间接（借助其它工具）地检测设计味道，并将它们作为技术债务的一部分，上述识别出的技术债务问题才会成为整个软件技术债务的一部分。

味道的严重程度如何？重构味道，偿还技术债务，需要多大的工作量？味道的严重性和重构味道所需的工作量取决于许多方面：现有类的大小、错位功能的大小和复杂度（即涉税计算）、代码库的其它部分在多大程度上使用了作为Order类一部分的涉税特性、现有类承担涉税职责的可能性、Order类单元测试的可用性等等。这看起来一点都不简单。

重构味道的工作项可能已经在待办事项中存在许多年了。维护软件的开发人员会发现很难理解为什么涉税功能会在Order类中。他们不得不围绕这个问题处理工作，不断地向/围绕涉税功能增加新的代码，使得在未来版本中对其重构更加困难。这就是所招致的技术债务（本金是原先走了捷径，将涉税功能添加到现有的Order类中）的利息部分。技术债务量化工具（据我们所知，目前所有的此类工具）在量化技术债务时忽视了利息部分。即使有任何工具考虑了利息部分，也很难（如果可能的话）准确地量化技术债务在认识、理解和处理作为Order类的一部分但与Order类不相关的涉税功能上增加了多大的困难。

还不相信吗？可以尝试在同样的代码库上运行不同的技术债务量化工具，然后交叉检验量化结果——你将会惊讶地发现，它们之间有多大的差别！

注意：我们无意冒犯任何工具供应商，因此，我们故意避免提及任何技术债务量化工具。我们也使用技术债务量化工具并且喜欢它们，但是我们也希望提醒读者注意它们的局限性，尤其是不要依赖它们生成的数值。

小结

技术债务很好地充当了沟通拙劣设计结果和持续重构需求的隐喻。当我们试图测量和量化技术债务时，它变得同准确测量软件生产力或者量化软件质量一样困难！

当然，工具量化技术债务的某些方面，分配货币值（或者参数化这些量化），有助于我们了解技术债务的程度，为我们提供一种跟踪技术债务偿还进度的方法。不过，需要谨慎对待它们提供的成本和工作量估计。

由于技术债务是走捷径或者做出次优设计决策所招致，所以债务本身就很难准确完整地量化（不像财务债务，数量和利息都可以清楚地计算出来）。务必将由工具得出的、从工作量和成本角度量化的技术债务当作 估计，仅仅是估计，而不是绝对真理 。

参考资料

[1] Ariadi Nugroho、Joost Visser、Tobias Kuipers.2011.An empirical model of technical debt and interest.第二届“技术债务管理”研讨会汇编.ACM，New York，NY，USA，1-8.DOI=10.1145/1985362.1985364.

[2] Vallary Singh、Will Snipes、Nicholas Kraft. A Framework for Estimating Interest on Technical Debt by Monitoring Developer Activity Related to Code Comprehension，第六届技术债务管理国际研讨会，国际软件维护与发展会议，2014（ICSME 2014）.

[3] Martin Fowler.“ 技术债务象限 ”.（最后访问2015.05.26）

[4] “ 重构软件设计味道：管理技术债务 ”，Girish Suryanarayana、Ganesh Samarthyam、Tushar Sharma，ISBN - 978-0128013977，Morgan Kaufmann/Elsevier，2014.

[5] Alexandra Szynkarski，同Ward Cunningham & Capers Jones的技术债务之争 .（最后访问2015.05.25）

[6] Designite——一个设计定量评估工具.（最后访问2015.05.26）

关于作者

Tushar Sharma 目前是印度班加罗尔西门子技术与服务分公司研究与技术中心的一名专家。他在西门子的工作涵盖软件设计、重构、设计味道、代码和设计质量、设计模式和变更影响分析等相关主题的研究，并提供咨询和培训。软件设计和重构是他的兴趣所在，他一直致力于这方面的研究，并获得了多项专利，发表了数篇研究论文及工具。他拥有位于印度钦奈的印度理工学院马德拉斯分校（IIT-M）计算机科学理工硕士（研究型）学位，专修设计模式和重构。他与人合著了两本书：第一本是2013年2月由Apress出版的“ Oracle Certified Professional Java SE 7 Programmer Exams 1Z0-804 and 1Z0-805 ”；第二本是2014年11月由Morgan Kaufmann出版的“ Refactoring for Software Design Smells: Managing Technical Debt ”。他是IEEE高级会员。他的Twitter账号为@Sharma__Tushar。

技术债务量化的局限：你依赖这些数值吗？ Ganesh Samarthyam 有超过12年的IT行业经验。他目前居于印度班加罗尔，是一名企业培训师兼独立顾问。在过去的6年中，他为西门子（班加罗尔公司研究与技术）的“软件架构和开发”团队工作。在为西门子工作之前，他在班加罗尔的Hewlett-Packard C++编译器团队工作了4.5年。在2005年到2007年间，他还代表HP担任ANSI/ISO C++标准委员会（JTC1/SC22/WG21）的成员。他是一名获得IEEE认证的软件工程认证讲师。他已经发表/与人合作发表了许多文章、研究论文和著作。他的最新著作“ Refactoring for Software Design Smells: Managing Technical Debt ”由Morgan Kaufmann/Elsevier出版（2014年11月）。更多信息请访问他的网站或者 LinkedIn页面][5] 。他的Twitter账号为@GSamarthyam。