一个童话故事
很久以前，有个软件开发团队找到他们的经理。“我们的项目有相当多的技术债务（Technical Debt），我们应该做点什么。”这个团队说。他们展示了一张图（图1）来说明项目的技术债务。“技术债务关系到项目质量。”他们说。并展示了技术债务各部分的分解，通过静态代码分析，能发现过于复杂的代码、重复的代码和冲突。“我们需要去除技术债务”他们告诉经理。
图1：SonarQube技术债务插件的结果报告
但经理困惑了：什么是技术债务？他该额外再增加$500.000的预算？为了什么？这关系到质量，但他不知道现在有什么缺陷。客户一直很满意，这些开发人员在说什么？因此经理和团队进行了长时间的讨论。
事实上，技术债务就是在这类讨论中引入的一个比喻。意思是低质量的代码就像是财务负担。债务的总额就是从代码库中把它们清除出去所需要付出的努力。利率是由于低质量代码造成的生产率下降。管理人员通常熟悉财务领域的术语，所以在谈论软件质量时使用这个比喻会更加容易沟通。
这个故事说明，技术债务这个比喻失败了。本以为在和经理沟通技术质量时，它能起到帮助作用，并最终产生回报。然而，现实并不那么容易。这是因为有技术债务并不意味着它必须要偿还。技术债务甚至不一定是件坏事，有时它只是为了按时上市或者达成项目其它目标而妥协的结果。甚至有时候这种情况无法避免，例如类库采用新技术或者进行了升级，导致原来没问题的代码现在产生了技术债务。关于技术债务该如何偿还，并没有简单的定律。事实上，偿还技术债务有多种方式，或者有时候你甚至可以将它作为你的优势[1]。
技术债务的问题
技术债务的主要问题是它只代表了系统的内部质量。而质量有哪些影响并不明确。特别是，技术债务的经济影响无法简单地用这个比喻来表示。技术债务还很奇怪。如果这些代码不需要修改，那技术债务就完全没关系。但是，一旦要修改这些代码，技术债务就成为代码的所有重要属性。所以，技术债务很可能对项目的成功、外部可见的质量完全没有影响。
但是如果你忽视项目的技术债务，很可能它就在某个地方等着你：如果你需要修改有大量技术债务的代码，成本可能非常高，最终无法执行。开发人员通常知道和害怕这类情形，维护有大量技术债务的代码不仅仅是少了乐趣，而是风险太高，因为bug很可能潜入，而评估很容易就被证明是错的。
因此，软件质量可能对软件项目的成功非常重要，而技术债务的比喻是不够的。它能用来表示软件质量，让人们了解软件质量怎么样，但如何处理软件质量才是真正重要的。
质量投资：修复代码的新比喻
也许换一个比喻更能说明对于软件系统的质量，我们该做什么。技术债务只反映修复质量问题所需支付的成本，上述例子中是$500.000。这个数字本身没有什么用处，它无法说明我们该如何处理这个问题，或者它们如何影响了系统的开发。也许我们该偿还技术债务，也许它完全没有影响。
所以一个更好的比喻也许是质量投资（Quality Investment）。使用质量投资，处理技术债务就有可能获得利润。这样就可以使用财务术语来积极地管理代码质量，可以很容易决定哪些质量问题应该解决，哪些可以暂时接受。
质量投资的想法来源于SQALE。SQALE方法[2][3]是一种质量模型，它定义了两种类型的成本：修复成本（remediation costs，RC）和非修复成本（non-remediation costs，NRC）。修复成本是指在你的代码库中清除某个质量问题的付出。事实上，修复成本可看作是技术债务。第二类成本更有趣。当这个质量问题未解决时，就会产生非修复成本。例如，开发某个新功能可能需要更长时间。这个额外的付出就是非修复成本。在这个上下文中，非修复成本看起来像是技术债务的利润。但事实上，这些成本应该给予更多考虑，例如不清理低质量代码的额外风险因素。利用SQALE，你可以选择维持当前的低质量状态，支付非修复成本，或者去提高质量，支付修复成本。
该质量模型的前期实现，例如SonarQube的SQALE插件，只支持修复成本。然而，这两种成本类型是经济合理地处理质量的关键，也是这个质量模型的创新性所在。
如果你正在提高质量，解决质量问题，那么支付的是修复成本。当问题清除后，团队避免了相应的非修复成本。因此，只有当非修复成本大于修复成本时，才值得去提高质量。因为只有这样，质量投资才能产生利润。这可以简单地用下面的利润公式来描述：
利润 =非修复成本 – 修复成本
这个公式给出了一个合理的、符合经济原则的指导方针，用于判断质量问题是否需要修复，以及何时修复。
正如之前提到的，代码的质量只有当它将来需要修改时，才会变得重要，因为只有这时候团队才会因为低质量代码而慢下来。所以，正确的投资分析必须评估代码将来修改的可能性，以及这两种类型的成本。因此，质量投资的比喻可以通过三个评估来实现。让我们看一个例子以便更深入地了解这一点。
假设我们有一个系统，它包括三个模块：客户、订单和发票。客户管理是个非常老的模块，已经不再开发了。因此，这个模块不适于质量投资：仅当代码被修改时才会产生修复成本，在这个例子中，修改的可能性为0%。因此支付任何修复成本都将导致损失。
然而，我们知道在接下来的迭代中，对订单流程进行了大量修改。根据经验，发票管理也必须进行一些修改。像这样的粗略估计通常是足够的，而且也很容易达成一致。经验告诉我们，详细的评估绝大多数都是假装精确。
接下来的步骤是要评估订单模块和发票模块的质量问题。订单管理的测试覆盖率非常低，客户管理的代码非常复杂，也就是说方法和类有大量的代码，并且有很多复杂的循环。面对众多选择，我们评估了修复成本和非修复成本。非修复成本的评估也应考虑模块修改的可能性。在下一个迭代中，如果代码质量相同，订单管理估计要投入20天。而如果测试覆盖率能提高，那么估计只需投入13天。因此，非修复成本是7天。这非常高，因为质量确实太差了，同时也因为有大量代码要修改。
订单管理：很低的测试覆盖率，修复成本：5天，非修复成本：7天
发票模块：很高的复杂度，修复成本：5天，非修复成本：4天
这些评估表明订单模块的质量投资产生了2天（=7天-5天）的利润。相反，发票模块的质量投资没有利润，甚至亏损。由此可见，投资于当前的订单系统是有价值的，因为根据团队的评估，提高测试覆盖率就有利润。对于发票模块，情况并不明确。就现在来说，其质量投资没有利润。然而，发票模块很可能在未来的几个迭代中也需要修改。这样你就能从发票模块的质量投资中得到利润。
根据给出的评估和计算出的利润，也可以为每个质量投资推算出投资回报（RoI）。投资回报表示相应的成本产生了多少利润。因此，投资回报率等于利润除以修复成本。订单模块质量投资的投资回报率大约是40%（=2天/5天）。经理们通常会寻找机会去获取比较高的投资回报率。使用这些财务术语，你能与他们沟通代码质量提高后的收益。当然，就像软件开发的几乎所有其它事情一样，这些数字都是估计值。然而，这显示了团队不只是基于自己的原因寻求提高质量，更重要的是由于经济原因。
质量投资这个比喻，让你能与管理者进行各种类型的讨论。除了技术债务的成本，你还可以与经理讨论节省时间和投入。对于经理来说，这意味着双赢局面：节省了预算，开发人员也很高兴，因为他们可以提高代码质量。同样，管理者可以考虑投资是否合适，或者一个快速但质量较低的解决方案也是足够的，甚至是必要的，因为要按时上市。
最后，质量投资是比较了众多评估的结果：什么是最经济的决定？但是，它回避了一个问题，为什么在软件开发中，很少使用投资这种想法。
以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索问题
， 技术
， 模块
， 代码
， 金融投资
， sonarqube
， 订单模块
， 投资
， 质量
， 代码质量
修复代码
债务工具投资、债务投资、债务性投资、vc投资有债务、夫妻一方投资所欠债务，以便于您获取更多的相关知识。