债务是一个复杂的话题。而软件开发工程师需要了解什么是技术债务以及如何有效管理技术债务以加速软件开发过程。
债务这个术语经常带有负面含义，而一提到债务，在人们脑海中经常会浮现贷款、医疗账单以及抵押贷款这样的景象。但实际上，一些金融债务实际上可以为人们提供帮助。
技术债务也是如此。技术债务(也称之为代码债务)是指开发团队加快交付今后可能需要重构的项目或功能时会发生的情况。对于开发团队来说，加快开发过程成为优先事项，而不是高质量的代码。
与金融债务一样，技术债务可能会为组织带来损害或可能提供帮助。为了明智地使用，软件工程师和团队领导者必须了解有多少技术债务并学会妥善管理。对于组织来说，这可能成为一项艰巨的任务，尤其是当他们对技术债务的利弊没有明确了解的时候。
技术债务是一个隐喻性框架，可以用于思考在开发团队加快软件生产之后需要重构的细节。
技术债务有哪些同义词?像大多数创造出来的术语一样，技术债务还有很多其他名称，它们基本上都意味着同一件事情。在谈论技术债务时，人们可能还会看到诸如……
技术债务(Techdebt)：技术债务的简写或昵称。
设计债务：与软件的设计元素有关的技术债务。
代码债务：与程序员必须重构的软件系统中的不良代码相关的技术债务。
这些术语都有细微的差别，但都属于更大的技术债务类别。
如何在Scrum框架中使用技术债务以及如何处理它Scrum如今已经成为软件开发人员在寻求以更有效的方式交付产品时使用的流行框架。Scrum的一个关键原则是事情是不可预测的：客户改变主意或经常出现新需求。这种对变化的开放，意味着组织在使用Scrum框架时可能会出现技术债务。
Scrum培训师StefanWolpers对Scrum中两种不同类型的技术债务进行了分析与阐述。
首先是主动选择创建由不完美代码组成的短期解决方案，以便可以更快地交付产品。期望开发团队会在初始发布之后并不断来改进代码质量。
当开发团队发现有关他们试图解决的问题的更多信息时，另一种类型的技术债务可能会出现。随着新需求的出现，以往有效的解决方案如今可能无法奏效。其代码需要调整和重构，这样就产生了一些技术债务。
Wolpers指出，Scrum指南并没有给出任何关于如何减少技术债务的具体指导。正如他所说，Scrum指南并没有提供万能的解决方案。尽管如此，他也认识到技术债务的积累是组织在开展业务时不可避免的一部分，并为Scrum团队来更好地处理他们基于代码的技术债务提供了六种方法。
他说，Scrum团队应该：
(1)优先考虑技术债务的透明度。Wolpers表示，透明度使管理技术债务变得更加简单。他建议开发团队突出展示他们的技术债务的可视化，将其作为首要任务，并在每次召开的Sprint会议期间审查他们的技术债务需求。
(2)跟踪技术债务。Wolpers建议对错误进行计数，并尽可能使用更深入的代码指标，如圈复杂度、代码覆盖率、SQALE评级以及规则。
(3)快速、定期地偿还债务。与金融债务一样，当团队定期偿还时，技术债务就会得到更好的管理。Wolpers表示，Scrum团队应该考虑将15%～20%的资源分配给每个Sprint周期的重构代码和修复错误。
(4)减少产品积压。组织的产品积压应该包括与偿还技术债务相关的任务。而组织将这些债务列入想要解决的问题，将有助于防止债务被忽视或遗忘。
(5)调整对“完成”的定义。在达到可管理的技术债务的既定标准之前，不要将某事视为已经完成。
(6)规范程序。为组织的团队如何处理添加实验或新功能(包括引入技术债务)制定一个可重复的公式。
技术债务有哪些不同类型?技术债务可以采取许多不同的形式，但还有很多人对于这些差异进行讨论。
而大多数专家都认同具有两种不同类型的技术债务：有意的和无意的。而这与Wolper将Scrum用户的主动和被动技术债务进行分离有些类似。
当组织为了缩短上市时间而选择在其代码中留出改进空间时，就会发生有意的技术债务(也称为故意或主动)。
当代码质量在一段时间后需要改进时，就会发生无意的技术债务(也称为偶然的、过时的、被动的或无意的)。这可能是第一次生产不佳的结果，或者只是随着代码过时而自然需要更新。
年发表的一篇名为《走向技术债务本体论》的学术论文对于只有两种类型的技术债务的观点进行了反驳。该论文指出，如果技术债务有更具体的类别，组织将会得到更好的服务，因此论文提出了13种不同类型的技术债务，每种类型都包括这篇论文指出的具体问题：
架构债务
积累债务
代码债务
缺陷债务
设计债务
文件债务
基础设施债务
人员债务
处理债务
要求债务
服务债务
测试自动化债务
测试债务
虽然这些债务分类方法还有其他细节，但最流行的债务分类方法来自MartinFowler的技术债务象限。与WardCunningham一样，MartinFowler是敏捷软件开发宣言的17位作者之一。然而当谈到技术债务时，Fowler独自开发了他所谓的“技术债务象限”。
MartinFowler的技术债务象限是什么?年，Fowler对由SteveMcConnel推广的有意和无意的技术债务的双重分离进行了细微的修改。他认为人们用债务进行比喻就像是问错了问题。
Fowler并没有试图找出有关设计缺陷的技术问题的答案，例如“这是否被视为技术债务?”，而是想知道这些软件系统产生的债务是鲁莽的还是谨慎的。这种区别，再加上“有意”或“无意”债务的概念，形成了Fowler所称的技术债务象限。
这个象限产生四种不同类型的技术债务：
鲁莽和有意。
鲁莽和无意。
谨慎和有意。
谨慎和无意。
有意债务发生在创造的选择中，无意债务发生在团队需要做出调整之后。然而，谨慎债务和鲁莽债务的区别更加独特，这种分类赋予了技术债务象限的价值。谨慎的技术债务来自一个知道自己在做什么的团队，而当他们做事过于草率时，就会产生鲁莽的债务。
能看出谨慎和鲁莽的区别吗?谨慎的团队了解他们的举动，并且他们有意使用他们的技术债务。
鲁莽的团队只是将他们的软件系统视为疯狂购物的美国运通银行持卡人，将导致技术债务不断地积累。
Fowler指出，用债务比喻来解释象限中最复杂的部分是谨慎和无意部分。而当一个团队知道他们在做什么并且在项目上做得很好但最终仍然需要一些返工时，就会出现这种情况。
Fowler表示，无论团队的专业知识或经验如何，软件工程团队都应该承担一定程度的债务。在谨慎的情况下出现少量债务是可以预料的，但这只会使减少鲁莽债务并尽可能减少不良代码而变得更加有价值。
应该始终避免哪种类型的技术债务?谨慎的技术债务可以为软件开发组织带来很多好处，但这些组织应该密切
转载请注明：http://www.0431gb208.com/sjsbszl/7799.html
