【.com快译】债这个词一般都会让人产生负面情绪。人们通常会联想到学生贷款、医疗账单和抵押贷款付款的画面。尽管如此，一些金融债务还是有一定好处的。技术债务也是如此。作为一个比喻，技术债务（也称为代码债务）是当开发团队需要在后期重构以加快项目或功能的交付时发生的情况。显然，优先考虑的是更快的开发过程，而不是更高质量的代码。与金融债务一样，技术债务对组织来说可能是一把双刃剑。为了明智地使用它，工程师和团队领导必须监控他们手头有多少技术债务，并学习如何妥善管理它。而对于组织而言，这将是一项艰巨的任务，尤其是当他们对技术债务的利弊没有清晰的认识时。技术债务的一个基本特征Scrum已经成为一种流行的框架，被希望以更有效的方式交付产品的软件开发人员使用。众所周知，客户经常有新的需求并改变主意。因此，开放式Scrum以事物的不可预测性为重要原则，允许用户在使用框架时产生技术债。在这里，我们借用了Scrum培训师StefanWolpers（参见--https://www.scrum.org/resources/blog/technical-debt-scrum-who-responsible#:~:text=%E2%80%9CTechnical%20debt%20(also%20known%20as,approach%20that%20would%20take%20longer.%E2%80%9D)已经提到有两种不同类型的Scrum技术债务：首先创建由绩效欠下的债务短期解决方案包括好的代码，以便开发团队可以更快地交付产品。同时，团队期望在初始发布后回过头来提高代码的质量。随着开发团队发现更多有关要解决的问题的信息，另一种技术债也是被动产生的，即：随着新需求的出现，过去行得通的方案将来可能行不通，因此这些需要调整重构的代码会包含一定的债务Wolper还认为：Scrum团队应该注意以下几个方面：为了便于管理，应优先考虑技术债的透明度。团队需要优先考虑技术债务的视觉突出显示，并在每个Sprint（冲刺）会议期间审查技术债务。跟踪技术债务。团队尽可能使用圈复杂度、代码覆盖率、SQALE评级和违反规则等深入的代码指标来记录和计算错误。快速并定期还清债务。Scrum团队应该考虑在每个Sprint周期中分配15-20%的资源用于重构代码和修复错误。对齐产品待办事项，将其与技术债务偿还任务联系起来。您可以将债务组织成待解决的Sprint状态，以帮助防止债务被遗忘。调整“完成”的定义：在满足管理技术债务的既定标准之前，不要将状态设置为完成。规范程序。为团队如何处理添加新功能（包括引入技术债务）制定可重复的公式。技术债务有哪些不同类型？目前，大多数专家普遍认为技术债有两种，一种是有意的，一种是无意的。其中：故意（也称为主动）技术债务发生在组织选择为代码改进留出空间以缩短上市时间时。当代码的质量在发布一段时间后需要改进时，就会出现无意的（也称为意外的、过时的、反应性的）技术债务。这些可能是第一次发布不佳的结果，或者由于过时的代码而自然需要更新。另一种观点提出了以下13种不同类型的技术债务，每一种都解决了标题中的特定问题，具体取决于技术的具体类别以及组织对更好服务的预期：架构债务建筑债务代码缺陷债务设计债务文档债务基础设施债务PersonnelDebtHandlingDebtNeedsDebtServiceDebtTestingAutomationDebtTestingDebtMartinFowler在有意和无意的分类中增加了鲁莽和审慎两个维度，提出了技术债务的四个象限。谨慎的技术债务来自知道如何做的团队，而鲁莽的技术债务则源于人们过于草率。两者之间的区别在于：谨慎的团队基于对他们行为的理解，有意使用技术债务。鲁莽的团队遭遇了越来越多的债务，仿佛刚刚经历了双十一购物节。可以看出，对于所有软件工程团队而言，无论其专业知识或经验如何，承担一定程度的债务都是可以接受的。也就是说，在谨慎的情况下，一些可预测的债务可以帮助团队了解如何处理手头的项目，以及以后要做的一些新工作。他们不仅会努力减少不计后果的债务，还会减少不良代码以提高软件质量。应始终避免哪种类型的技术债务？审慎的技术债务虽然对软件组织有利，但如果积累过多，也会变成鲁莽的技术债务。也就是说，当软件随着时间的推移退化产生错误，甚至影响其功能和可用性时，就会变成Bitrot（也称为“软件熵”）。例如：当开发人员需要对他们不太了解的历史遗留代码进行小的增量更改时，软件本身的复杂性和潜在问题就会增加。有些工程师甚至可能违反NFR（Non-functionalrequirement，非功能性需求），完全破坏代码，进而影响软件的整体功能。解决这种技术债务的唯一方法是重构整个流程。而且，在大多数情况下，团队中的一些小变化是他们自己没有意识到的，而实际上导致了总债务的增加。虽然我们也可以使用Wolper的透明度概念来帮助避免此类灾难，但从根本上说，团队应该对目标软件有足够的了解，以避免无意中添加可能阻塞系统的代码。技术债的指标是什么？与任何良好的管理计划类似，组织需要了解指标以控制技术债务。以下是一些值得参考和衡量的指标：软件缺陷软件开发人员应持续记录和跟踪发现的缺陷，包括未修复的缺陷和已修复的缺陷。对于未修复的缺陷，开发团队可以在敏捷迭代中持续关注并修复。通过跟踪已修复的缺陷，团队可以衡量他们的技术债务管理流程和效率。代码质量如果说软件缺陷直接影响到软件的最终用户，那么代码的复杂性就会阻碍团队的开发和维护。以下是代码复杂度的指标：圈复杂度类耦合代码行数继承深度当然，这些指标应该越低越好。通过密切关注这些指标，团队还能够准确了解需要重写或重构哪些代码以降低复杂性并改进软件的后端。代码内聚类似于代码质量，关注代码内聚将有助于简化代码复杂性。更高的代码内聚通常意味着目标代码更易于维护、可重用和健壮。同时，该指标还可以最大限度地减少所需的开发人员数量，并大大降低复杂度并减少Bitrot。代码所有权“多手”在这里可以用来形容更多的开发人员，导致更多的工作量，导致更大的问题，以及更多无意的技术债务。因此，我们需要提供“代码所有权”指标来回答“谁在关注哪段代码？”等问题。和“如果有问题我应该联系谁？”这些指标将向项目经理显示有多少人在处理一段代码，以及在控制上花费了多少时间。据此，我们可以避免由于完整的代码部分掌握在某位成员手中而导致他可能被堵在路上而耽误项目进度等单点故障。因此，我们可以将代码库拆分到不同的领域，然后委托给团队中不同的开发人员角色。代码更改(Churn)重写或替换代码段等活动可以视为代码更改。如果开发人员必须围绕某段代码不断解决类似的错误，则意味着这里的技术债务非常严重。由此，团队还可以识别并确定代码的哪些部分需要重构。因此，团队需要特别关注频繁变动的代码，以便快速发现问题，避免问题的加剧和技术债的积累。值得一提的是，单纯跟踪上述技术债的各项指标并不能自动消除所有的债，我们还需要更有效的管理实践。关于技术债务的调查基于卡内基梅隆大学软件工程学院的行业调查（参见--https://insights.sei.cmu.edu/sei_blog/2015/07/a-field-study-of-technical-debt.html)发现糟糕的架构通常是技术债务的第一大来源，其次是过于复杂的代码，第三是文档和测试之间缺乏强有力的联系。更糟糕的是，65%的受访者表示他们没有适当的技术债务管理应用程序。这意味着他们选择不实施任何解决方案，因为他们缺乏处理技术债务的策略！一位拥有超过20年服务经验的软件开发人员，服务范围从《财富》500到初创公司，他建议：开发团队应该像投资信用卡业务一样投资技术债务，投资的重点应该放在以下两个地方：公司的文化，将人们映射到复杂的系统并履行职责。构建代码库，执行更深入和更频繁的质量保证测试。在组织积累了大量技术债务的情况下，您可以自动执行此类测试。至少投资某种形式的代码审查，以确保尽早解决问题。当然，这也意味着更频繁的重构。然而，在上述两个领域的投资只是一个起点，我们仍然强调需要管理好自己的技术债。如上述调查所述，如果没有明确的战略，技术债务将继续增加，并在线上和线下产生更多问题。如何管理技术债务？就像金融债务一样，技术债务只能通过计划和实施管理来减少。当然，俗话说“知行合一”，我们要做到这一点并不容易。它需要不断的监控和输入，是软件开发不可或缺的一部分。而且，由于技术债务很容易与业务目标脱节，对其进行管理有助于使开发与业务目标保持一致。据预测，到2024年，技术债务将使全球科技公司损失4万亿美元。实施技术债务管理和补救的公司将客户产品交付时间减少50%。目前，市场上一些新技术应用已经捕捉到了这样的软件需求，并提出了相应的解决方案。例如，像Stepsize这样的软件可以让开发团队轻松获取债务报告、对其进行分类，并确定要解决的最重要的债务。通过监控和管理积累的任何技术债务，他们可以帮助软件工程团队及时交付出色的软件产品，而无需彻底改变正常的工作流程。原标题：工程师的技术债完全指南，作者：AlexOmeyer
