【.com快译】债务是一个复杂的话题。软件开发工程师需要了解什么是技术债以及如何有效管理技术债以加快软件开发进程。债务一词通常带有负面含义，当提到债务时，人们脑海中常常浮现出贷款、医疗费和抵押贷款。但在现实中，一些金融债务实际上可以帮助人们。技术债务也是如此。技术债务（也称为代码债务）是指开发团队加快交付未来可能需要重构的项目或功能时发生的情况。对于开发团队来说，加快开发过程成为当务之急，而不是高质量的代码。与金融债务一样，技术债务可以损害或帮助组织。要明智地使用它，软件工程师和团队领导者必须了解存在多少技术债务并学会妥善管理它。对于组织而言，这可能成为一项艰巨的任务，尤其是当他们对技术债务的利弊没有清晰的认识时。技术债务是一个隐喻框架，可以用来思考开发团队加速软件生产后需要重构的细节。技术债务的一些同义词是什么？与大多数创造的术语一样，技术债务有许多其他名称，基本上意思相同。在谈论技术债务时，人们可能还会看到诸如...技术债务：技术债务的简称或昵称。设计债务：与软件设计元素相关的技术债务。代码债务：与软件系统中的错误代码相关的技术债务，程序员必须重构。这些术语都略有不同，但都属于更大的技术债务类别。如何在Scrum框架中使用技术债务以及如何处理Scrum已成为当今软件开发人员在寻求以更高效的方式交付产品时使用的流行框架。Scrum的一个关键原则是事情是不可预测的：客户改变主意或新需求频繁出现。这种对变化的开放态度意味着组织在使用Scrum框架时可能会产生技术债务。Scrum培训师StefanWolpers分析和解释了Scrum中两种不同类型的技术债务。第一个是主动选择创建由不完美代码组成的短期解决方案，以便更快地交付产品。期望开发团队在初始发布后不断提高代码质量。当开发团队发现更多关于他们试图解决的问题时，可能会出现另一种类型的技术债务。随着新需求的出现，过去行之有效的解决方案今天可能行不通。它的代码需要调整和重构，这会产生一些技术债务。Wolpers指出，Scrum指南没有给出任何关于如何减少技术债务的具体指导。正如他所说，Scrum指南并没有提供一种放之四海而皆准的解决方案。尽管如此，他还是认识到技术债务的积累是组织开展业务不可避免的一部分，并为Scrum团队提供了六种方法来更好地处理基于代码的技术债务。他说，Scrum团队应该：(1)优先考虑技术债务的透明度。Wolpers说，透明度使管理技术债务变得更简单。他建议开发团队将技术债务的可视化作为重中之重，并在每次冲刺会议期间审查他们的技术债务需求。(2)跟踪技术债务。Wolpers建议对错误进行计数，并在可能的情况下使用更深层次的代码指标，例如圈复杂度、代码覆盖率、SQALE评级和规则。(3)迅速而定期地偿还债务。与金融债务一样，技术债务在团队定期偿还时得到更好的管理。Wolpers说，Scrum团队应该考虑在每个Sprint中分配15%到20%的资源来重构代码和修复错误。(4)减少产品积压。组织的产品积压工作应包括与偿还技术债务相关的任务。将这些债务列为组织想要解决的问题将有助于防止它们被忽视或遗忘。(5)调整“完成”的定义。在达到可管理的技术债务的既定标准之前，不要认为某件事已经完成。（六）规范程序。为您组织的团队如何添加实验或新功能（包括引入技术债务）制定可重复的公式。技术债务有哪些不同类型？技术债务可以有许多不同的形式，但是关于这些差异有很多讨论。大多数专家都认为有两种不同类型的技术债务：有意的和无意的。而这有点类似于Wolper对Scrum用户的主动和被动技术债务的分离。当组织选择在其代码中留出改进空间以缩短上市时间时，就会发生故意技术债务（也称为蓄意或主动）。无意的技术债务（也称为偶然的、过时的、反应性的或无意的）发生在一段时间后需要提高代码质量时。这可能是第一次制作不佳的结果，或者只是随着代码过时而自然需要更新。2014年发表的一篇名为《走向技术债务本体论》的学术论文驳斥了技术债务只有两种类型的观点。该论文指出，如果有更具体的技术债务类别，组织会得到更好的服务，因此该论文提出了13种不同类型的技术债务，每一种都包括该论文确定的具体问题：架构债务积累债务代码债务缺陷债务设计债务文档债务基础设施债务人员债务处理债务要求债务服务债务测试自动化债务测试债务虽然这些债务分类方法还有其他详细信息，但最流行的债务分类方法来自MartinFowler的技术债务象限。与WardCunningham一起，MartinFowler是敏捷软件开发宣言的17位作者之一。然而，当谈到技术债务时，福勒自己开发了他所谓的“技术债务象限”。什么是MartinFowler的技术债务象限？2009年，Fowler对SteveMcConnel推广的有意和无意技术债务的双重分离进行了轻微修改。他认为人们使用债务比喻就像问错了问题。Fowler没有试图找到有关设计缺陷的技术问题的答案，例如“这是否被视为技术债务？”，而是想知道这些软件系统招致的债务是鲁莽的还是谨慎的。这种区别与“有意”或“无意”债务的概念相结合，形成了福勒所说的技术债务象限。该象限产生四种不同类型的技术债务：鲁莽的和故意的。鲁莽而无意。小心而有意。谨慎和无意。有意的亏欠发生在创造的选择上，无心的亏欠发生在团队需要做出调整之后。然而，审慎债务和鲁莽债务之间有一个更独特的区别，这种分类赋予了技术债务象限其价值。谨慎的技术债务来自于一个知道自己在做什么的团队，而鲁莽的技术债务来自于他们做事太马虎。你能看出谨慎和鲁莽之间的区别吗？谨慎的团队了解他们的举动，并且他们有意使用他们的技术债务。鲁莽的团队就像对待疯狂购物的美国运通持卡人一样对待他们的软件系统，技术债务不断堆积。福勒指出，使用债务比喻来解释象限中最复杂的部分是谨慎和无意的部分。当一个团队知道他们在做什么并且在项目上做得很好但最终仍然需要一些返工时，就会发生这种情况。Fowler说，无论团队的专业知识或经验如何，软件工程团队都应该承担一定程度的债务。在审慎的情况下，少量的债务是可以预料的，但这只会让减少不计后果的债务和尽量减少错误代码变得更有价值。人们应该始终避免哪种类型的技术债务？谨慎的技术债务可以为软件开发组织带来很多好处，但这些组织应该密切关注他们积累了多少技术债务。鲁莽从来都不是好事，但还有另一种类型的技术债务会对组织造成更大的损害：比特腐烂。当软件随着时间的推移退化到产生错误甚至改变其功能和可用性的程度时，就会发生位腐烂（也称为“数据损坏”）。Bitdecay需要一定的开发时间，但会让开发团队更加谨慎。这通常发生在开发人员对他们不完全理解的遗留代码进行增量、小的更改时。这些小的变化最终会产生足够的复杂性和问题来影响整个软件。一些软件开发工程师甚至可能违反非功能需求(NFR)或完全破坏代码。解决这个技术债务的唯一方法是重构整个系统。而技术债最大的问题在于，微小的改动实际上会增加债务的总量，而大多数时候开发团队甚至都不知道。使用Wolper的透明度概念可以帮助组织避免此类灾难。同样，开发团队将从充分了解他们工作的每个软件中受益，这样他们就不会无意中添加可能阻碍系统运行的代码。项目管理团队可以通过确保他们的开发过程不会为比特腐烂的发生留下空间来追究他们的开发人员的责任。什么是技术债务指标？了解很多关于技术债务的知识并不重要，除非你可以衡量它。但是应该测量什么？与任何良好的管理计划一样，组织需要了解最佳指标以控制其技术债务。以下是一些需要关注的最佳指标：(1)错误至少，软件开发人员应该计算并跟踪他们的错误。这包括已修复和未修复的错误。关注未修复的错误可以让开发团队在敏捷迭代期间关注并修复它们。专注于已修复的错误有助于团队衡量其技术债务管理流程的有效性。(2)代码质量虽然错误对软件的最终用户有更直接的影响，但代码复杂性确实会损害开发团队和整个组织。寻找代码复杂度指标，例如：圈复杂度。类耦合。代码行。传承深度。这些指标越低越好。密切关注这些指标还可以帮助组织准确了解要返工或重构哪些代码以降低复杂性并改进软件的后端。(3)代码内聚与代码质量一样，专注于代码内聚将有助于防止您的代码变得过于复杂。高代码内聚通常意味着代码更易于维护、可重用和健壮。它还最大限度地减少了需要参与代码开发的人数，这可以显着降低复杂性并减少位腐烂的机会。高内聚意味着拥有一个执行定义明确的任务的类。(4)拥有更多代码所有权的开发工程师通常意味着更多的麻烦，而更多的麻烦通常会导致更大的问题和更高水平的无意识技术债务。这就是为什么代码所有权是一个如此有价值的指标：它回答了“谁在编写什么代码？”的问题。该指标将使组织的项目经理关注处理各种代码的人数。了解这些信息将使这些团队能够减少投入这些工作的开发人员的数量和时间。但是您不希望某人拥有完整的代码片段以防他们离开或发生事故。通常，开发工程师团队拥有代码库中的域。(5)Churn代码被改写/替换时称为Churn。Churn是对给定代码段看到的活动的度量。组织需要关注大量活动代码，因为其中的任何问题都可能加剧。然后衡量流失率可以帮助团队确定代码的哪些部分需要重构并确定其优先级。如果开发工程师必须不断解决代码同一部分中的错误，则说明那里出了问题。关注这种流失将帮助组织更快地查明这些问题，使他们能够通过永久解决方案解决问题，从而减少技术债务。跟踪这些技术债务指标不会消除您组织的所有债务，但有助于更有效地管理它。什么是技术债务统计？一些研究机构进行了学术研究和调查，阐明了软件行业对技术债务隐喻的看法。卡内基梅隆大学软件工程研究所的一项行业调查发现，大多数参与者发现了隐喻的一些价值，尽管他们在确切定义上略有不同。然而，更有趣的是他们关于技术债务成因的发现。受访者表示，首先，糟糕的架构选择是他们技术债务的主要来源。二是代码过于复杂，三是缺乏文档和测试不足。这些结果表明，大多数受访者表示他们无意中积累了技术债务。更糟糕的是，65%的参与者表示他们没有管理技术债务的流程。这意味着他们积累了技术债务，因为他们缺乏战略并且选择不制定解决这些问题的战略。一位拥有20多年与多家公司合作经验的软件开发人员建议，组织应该像还清信用卡一样还清技术债务。组织应该将投资集中在两个地方：企业文化和代码库。投资于企业文化似乎可以让每个人都达成共识。这意味着创建一个让人们负责的系统，这意味着人们知道他们在做什么。投资代码库可能意味着执行更深入和更频繁的质量保证测试。这些测试甚至可以自动化。这也可能意味着更频繁的重构，尤其是在组织积累了大量技术债务的情况下。对代码库的投资应该包括某种形式的代码审查，以确保问题在失控之前得到解决。投资这些地方是一个很好的起点，但任何组织可以做的最有价值的事情就是管理他们的技术债务。如果没有明确的战略，技术债务将继续增长，并在未来引发更多问题。你如何开始管理技术债务？与金融债务一样，技术债务只有在您有管理计划的情况下才会减少。但管理技术债务并不容易。它需要频繁的监控和努力，并已成为软件公司的重要组成部分。技术债务很容易分散组织对业务目标的注意力，因此对其进行管理有助于与组织的其他部门保持一致。尽管如此，管理技术债务对组织来说仍然是一种负担。项目经理、产品团队和工程师已经不堪重负。这难道不是他们最初积累债务的原因吗？添加其他东西会增加他们的压力水平吗？也许是这样，但想要保持低技术债务的组织必须将其作为优先事项。这是一个很大的需求，尤其是在查看统计数据时。据研究机构预测，到2024年，未解决的技术债务将使全球企业损失4万亿美元，而那些偿还技术债务的企业将缩短50%的交付时间给客户。在过去的几年里，新技术的应用让软件公司认识到了这种需求，并寻求满足这种需求的方法。现在，借助Stepsize等软件，开发团队可以轻松报告债务、对债务报告进行分类并确定需要解决的最重要的债务部分，从而帮助组织管理其技术债务。所有这些都有助于软件工程团队管理他们的技术债务，而无需彻底改变他们的常规工作流程。更重要的是，它使他们能够快速开发出色的软件，同时监控他们积累的技术债务。原作者：TheEngineer'sCompleteGuidetoTechnicalDebt，作者：AlexOmeyer
