软件开发工程师技术债务的完整指南

债务是一个复杂的话题。而软件开发工程师需要了解什么是技术债务以及如何有效管理技术债务以加速软件开发过程。

债务这个术语经常带有负面含义，而一提到债务，在人们脑海中经常会浮现贷款、医疗账单以及抵押贷款这样的景象。但实际上，一些金融债务实际上可以为人们提供帮助。

技术债务也是如此。技术债务(也称之为代码债务)是指开发团队加快交付今后可能需要重构的项目或功能时会发生的情况。对于开发团队来说，加快开发过程成为优先事项，而不是高质量的代码。

与金融债务一样，技术债务可能会为组织带来损害或可能提供帮助。为了明智地使用，软件工程师和团队领导者必须了解有多少技术债务并学会妥善管理。对于组织来说，这可能成为一项艰巨的任务，尤其是当他们对技术债务的利弊没有明确了解的时候。

技术债务是一个隐喻性框架，可以用于思考在开发团队加快软件生产之后需要重构的细节。

技术债务有哪些同义词?

像大多数创造出来的术语一样，技术债务还有很多其他名称，它们基本上都意味着同一件事情。在谈论技术债务时，人们可能还会看到诸如……

• 技术债务(Tech debt)：技术债务的简写或昵称。
• 设计债务：与软件的设计元素有关的技术债务。
• 代码债务：与程序员必须重构的软件系统中的不良代码相关的技术债务。

这些术语都有细微的差别，但都属于更大的技术债务类别。

如何在Scrum框架中使用技术债务以及如何处理它

Scrum如今已经成为软件开发人员在寻求以更有效的方式交付产品时使用的流行框架。Scrum的一个关键原则是事情是不可预测的：客户改变主意或经常出现新需求。这种对变化的开放，意味着组织在使用Scrum框架时可能会出现技术债务。

Scrum培训师Stefan Wolpers对Scrum中两种不同类型的技术债务进行了分析与阐述。

• 首先是主动选择创建由不完美代码组成的短期解决方案，以便可以更快地交付产品。期望开发团队会在初始发布之后并不断来改进代码质量。
• 当开发团队发现有关他们试图解决的问题的更多信息时，另一种类型的技术债务可能会出现。随着新需求的出现，以往有效的解决方案如今可能无法奏效。其代码需要调整和重构，这样就产生了一些技术债务。

Wolpers指出，Scrum指南并没有给出任何关于如何减少技术债务的具体指导。正如他所说，Scrum指南并没有提供万能的解决方案。尽管如此，他也认识到技术债务的积累是组织在开展业务时不可避免的一部分，并为Scrum团队来更好地处理他们基于代码的技术债务提供了六种方法。

他说，Scrum团队应该：

(1)优先考虑技术债务的透明度。Wolpers表示，透明度使管理技术债务变得更加简单。他建议开发团队突出展示他们的技术债务的可视化，将其作为首要任务，并在每次召开的Sprint会议期间审查他们的技术债务需求。

(2)跟踪技术债务。Wolpers建议对错误进行计数，并尽可能使用更深入的代码指标，如圈复杂度、代码覆盖率、SQALE评级以及规则。

(3)快速、定期地偿还债务。与金融债务一样，当团队定期偿还时，技术债务就会得到更好的管理。Wolpers表示，Scrum团队应该考虑将15%～20%的资源分配给每个Sprint周期的重构代码和修复错误。

(4)减少产品积压。组织的产品积压应该包括与偿还技术债务相关的任务。而组织将这些债务列入想要解决的问题，将有助于防止债务被忽视或遗忘。

(5)调整对“完成”的定义。在达到可管理的技术债务的既定标准之前，不要将某事视为已经完成。

(6)规范程序。为组织的团队如何处理添加实验或新功能(包括引入技术债务)制定一个可重复的公式。

技术债务有哪些不同类型?

技术债务可以采取许多不同的形式，但还有很多人对于这些差异进行讨论。

而大多数专家都认同具有两种不同类型的技术债务：有意的和无意的。而这与Wolper将Scrum用户的主动和被动技术债务进行分离有些类似。

当组织为了缩短上市时间而选择在其代码中留出改进空间时，就会发生有意的技术债务(也称为故意或主动)。

当代码质量在一段时间后需要改进时，就会发生无意的技术债务(也称为偶然的、过时的、被动的或无意的)。这可能是第一次生产不佳的结果，或者只是随着代码过时而自然需要更新。

2014年发表的一篇名为《走向技术债务本体论》的学术论文对于只有两种类型的技术债务的观点进行了反驳。该论文指出，如果技术债务有更具体的类别，组织将会得到更好的服务，因此论文提出了13种不同类型的技术债务，每种类型都包括这篇论文指出的具体问题：

• 架构债务
• 积累债务
• 代码债务
• 缺陷债务
• 设计债务
• 文件债务
• 基础设施债务
• 人员债务
• 处理债务
• 要求债务
• 服务债务
• 测试自动化债务
• 测试债务

虽然这些债务分类方法还有其他细节，但最流行的债务分类方法来自Martin Fowler的技术债务象限。与Ward Cunningham一样，Martin Fowler是敏捷软件开发宣言的17位作者之一。然而当谈到技术债务时，Fowler独自开发了他所谓的“技术债务象限”。

Martin Fowler的技术债务象限是什么?

2009年，Fowler对由Steve McConnel推广的有意和无意的技术债务的双重分离进行了细微的修改。他认为人们​​用债务进行比喻就像是问错了问题。

Fowler并没有试图找出有关设计缺陷的技术问题的答案，例如“这是否被视为技术债务?”，而是想知道这些软件系统产生的债务是鲁莽的还是谨慎的。这种区别，再加上“有意”或“无意”债务的概念，形成了Fowler所称的技术债务象限。

这个象限产生四种不同类型的技术债务：

• 鲁莽和有意。
• 鲁莽和无意。
• 谨慎和有意。
• 谨慎和无意。

有意债务发生在创造的选择中，无意债务发生在团队需要做出调整之后。然而，谨慎债务和鲁莽债务的区别更加独特，这种分类赋予了技术债务象限的价值。谨慎的技术债务来自一个知道自己在做什么的团队，而当他们做事过于草率时，就会产生鲁莽的债务。

能看出谨慎和鲁莽的区别吗?

谨慎的团队了解他们的举动，并且他们有意使用他们的技术债务。

鲁莽的团队只是将他们的软件系统视为疯狂购物的美国运通银行持卡人，将导致技术债务不断地积累。

Fowler指出，用债务比喻来解释象限中最复杂的部分是谨慎和无意部分。而当一个团队知道他们在做什么并且在项目上做得很好但最终仍然需要一些返工时，就会出现这种情况。

Fowler表示，无论团队的专业知识或经验如何，软件工程团队都应该承担一定程度的债务。在谨慎的情况下出现少量债务是可以预料的，但这只会使减少鲁莽债务并尽可能减少不良代码而变得更加有价值。

应该始终避免哪种类型的技术债务?

谨慎的技术债务可以为软件开发组织带来很多好处，但这些组织应该密切关注他们积累了多少技术债务。鲁莽从来都不是好事，但存在另一种可能对组织造成更大伤害的技术债务：位衰减(bit rot)。

位衰减(也称为“数据腐化”)发生在软件随着时间的推移而退化到产生错误甚至改变其功能和可用性的程度时。位衰减需要一些时间来开发，但它将让开发团队更加谨慎。

当开发人员对他们不完全理解的遗留代码进行增量的微小更改时，通常会发生这种情况。这些微小的更改最终会造成足够的复杂性和问题，从而影响整个软件的。一些软件开发工程师甚至可能违反非功能性要求(NFR)或完全破坏代码。解决这种技术债务的唯一方法是重构整个系统。

而技术债务面临最大的问题是，微小的变化实际上会增加债务总额，而且开发团队在大多数时候甚至不知道这一点。使用Wolper的透明度概念可以帮助组织避免这样的灾难。

同样，开发团队将从完全理解他们工作的每个软件中受益，这样他们就不会无意中添加可能阻碍系统运行的代码。项目管理团队可以通过确保他们的开发过程不会留下发生位衰减的空间来让他们的开发人员负责。

什么是技术债务指标?

除非能够衡量它，否则了解很多关于技术债务的知识并不重要。

但是应该衡量什么? 与任何良好的管理计划一样，组织需要了解最佳指标才能控制其技术债务。

以下是一些值得关注的最佳指标：

(1)错误(Bug)

至少，软件开发人员应该计算并跟踪他们的错误。这包括已修复和未修复的错误。而关注未修复的错误可以让开发团队在敏捷迭代期间专注于并修复它们。关注已修复的错误有助于团队衡量他们的技术债务管理流程的有效性。

(2)代码质量

虽然错误对软件的最终用户有更直接的影响，但代码复杂性确实会损害开发团队和整个组织。

寻找代码复杂性指标，例如：

• 圈复杂度。
• 类耦合。
• 代码行。
• 继承深度。

这些指标越低越好。

密切关注这些指标还有助于组织准确地知道要返工或重构哪些代码，以降低复杂性并改进软件的后端。

(3)代码内聚

与代码质量一样，专门关注代码内聚性将有助于避免代码变得过于复杂。高代码内聚通常意味着代码更易于维护、可重用和健壮。它还最大限度地减少了需要参与代码开发的人数，这可以显著降低复杂性，并减少位衰减的机会。

高内聚性是指有一个类执行定义良好的任务。

(4)代码所有权

更多的开发工程师通常意味着更多的麻烦，而更多的麻烦通常会导致更大的问题和更高水平的无意技术债务。这就是为什么代码所有权是一个如此有价值的指标：它回答了“谁专注于什么代码?”的问题。

该指标将使组织的项目管理人员关注处理各种代码的人数。了解这些信息将使这些团队能够减少用于这些工作的开发人员的人数和时间。但并不希望某个人拥有完整的代码段，以防万一离职或者出现意外。通常情况下，是让开发工程师团队拥有代码库中的域。

(5)Churn

代码在被重写/替换时被称之为Churn。Churn是对给定代码段看到的活动的度量。组织要关注到大量活动的代码，因为其中的任何问题都会加剧。然后，度量流失可以帮助团队识别代码的哪些部分需要重构并确定其优先级。如果开发工程师必须不断解决代码同一部分的错误，那就意味着那里出了问题。关注这种流失将帮助组织更快地查明这些问题，使他们能够通过永久性解决方案来解决问题，从而降低技术债务。

跟踪这些技术债务指标不会消除组织的所有债务，但会帮助更有效地管理。

什么是技术债务统计?

一些研究机构已经进行了学术研究和调查，阐明了软件行业对技术债务比喻的看法。

卡内基梅隆大学软件工程研究所的一项行业调查发现，大多数参与者在这个比喻中发现了一些价值，尽管他们对具体定义略有不同。然而更有趣的是，他们关于技术债务成因的研究结果。

受访者表示，第一，糟糕的架构选择是他们技术债务的主要来源。第二是代码过于复杂，第三是缺乏文档和测试不充分。

这些结果表明，大多数受访者表示无意中积累了技术债务。更糟糕的是，65%的参与者表示他们没有管理技术债务的流程。这意味着他们因为缺乏战略而积累了技术债务，并且选择没有解决这些问题的战略。

一位拥有20多年与各种公司合作经验的软件开发人员建议，组织应该像还清信用卡一样偿还他们的技术债务。组织应该将投资重点集中在两个地方：企业文化和代码库。

投资于企业文化似乎让每个人都站在同一个立场上。这意味着要建立起让人们共同负责的制度，意味着人们知道在做什么。

而投资于代码库可能意味着执行更深入和更频繁的质量保证测试。这些测试甚至可能是自动化的。这也可能意味着更频繁的重构，特别是如果组织已经积累了大量技术债务的话。投资于代码库应该包括某种形式的代码审查，以确保在问题变得失控之前得到解决。

在这些地方投资是很好的起点，但任何组织可以做的最有价值的事情就是管理他们的技术债务。如果没有明确的战略，技术债务将会继续增长，并在未来带来更多问题。

如何开始管理技术债务?

与金融债务一样，只有制定计划加以管理，技术债务才会减少。但管理技术债务并非易事。它需要频繁的监控和努力，并且已经成为软件公司必不可少的一部分。技术债务很容易使组织偏离业务目标，因此管理它有助于与组织的其他部分保持一致。

尽管如此，管理技术债务对于组织来说仍然感觉是一种负担。项目经理、产品团队和工程师已经不堪重负。这不是他们首先累积债务的原因吗?而添加其他东西会增加他们的压力水平吗?也许是这样，但想要将技术债务保持在较低水平的组织必须将其作为优先事项。这只是一个很大的需求，尤其是当查看统计数据时。

根据调研机构的预测，到2024年，尚未解决的技术债务将使全球各地的公司损失4万亿美元，而那些偿还技术债务的企业向客户的交货时间将缩短50%。

在过去的几年中，新技术应用程序已经让软件公司认识到这种需求，并寻求方法来满足它。

现在，有了Stepsize之类的软件，开发团队可以轻松地报告债务、对债务报告进行分类，并确定需要解决的最重要的债务部分，从而帮助组织管理其技术债务。所有这些都有助于软件工程团队管理他们的技术债务，而不会彻底改变他们的常规工作流程。更重要的是，它使他们能够快速开发出优秀的软件，同时监控他们积累的技术债务。

原文作者：The Engineer’s Complete Guide to Technical Debt，作者：Alex Omeyer

当前题目：软件开发工程师技术债务的完整指南
网站地址：http://www.shufengxianlan.com/qtweb/news34/471584.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联