技术债务听起来像是一个财务术语，这正是该编程理论的根源所在。在软件开发方面，技术债务是指某些必要的工作在软件项目的开发过程中被延迟，以达到可交付成果或截止日期。
技术债务是你明天必须做的编码，因为你为了今天交付软件而走了捷径。
以使用 Visual Basic (VB) 脚本更新简单的 Excel 宏工作表 (.xlsm) 为例。新的 VB 代码在 Excel 2013 下运行良好，但在 Excel 365 下运行时挂起。与其重新配置宏以在 Excel 2013和Excel 365 下运行，不如将代码投入生产，仅适用于 Excel 2013，以便立即交付增强功能. 服务台开始推出 Office 365，令人惊讶的是，宏不再有效。这块技术债刚刚到期：必须有人重新配置 VB 代码才能在 Excel 365 下正常工作。
在本文中，我们将深入探讨技术债务，探讨所有这些主题：
目录
技术债务：当足够好时变得完美
从本质上讲，开发人员总是必须平衡这个问题：开发设计完美的应用程序、软件、系统等，还是发布足够好的代码。干净、设计良好的代码使未来的迭代和创新更容易实现。然而，在商业环境中，截止日期和有限的资源通常会阻止开发人员在交付产品之前生成干净、完美的代码。
这就是技术债务发挥作用的地方。该概念认识到完美产品与产品交付通常需要的较短时间之间的权衡。虽然承担一些债务可能是有用的，就像金钱问题一样，但你想要承担多少债务是有限制的。
定义技术债务和 cruft
技术债务的概念是，“债务”代表了在短期内实现平庸代码时产生的额外开发工作，尽管它不是质量最好的整体解决方案。平庸的代码——通常是冗余的、设计糟糕的、无用的，或者三者兼而有之——被称为cruft。
敏捷编程的创始人之一Ward Cunningham在 1990 年代初首次讨论了这个概念。坎宁安今天继续谈论这个话题——他在这里解释技术债务：
技术债务的确切定义是什么？卡内基梅隆大学软件工程研究所指出，技术债务“概念化了快速交付的短期利益与长期价值之间的权衡。” 另一个观点来自行业分析师 Gartner，将技术债务定义为应用程序偏离任何非功能性需求。
下面是一个一般示例：假设您是一名软件开发人员，您必须向软件或系统添加新功能。有两种路径可供选择：
- 由更混乱的代码或设计组成的更简单的路线将使您更快地到达目的地。
- 由更清晰的代码和设计组成的更难的路线将花费更多时间。
与货币债务一样，技术债务可以积累“利息”。在这个概念中，有趣的是以后实施更改的难度会越来越大，尤其是当软件项目多米诺骨牌经历多个阶段时。技术债务被忽视或未解决的时间越长，软件熵就越大。
技术债务就像把所有东西都藏在沙发底下打扫卫生——暂时还算整洁，但没有什么东西在正确的位置。您最终将不得不花时间在路上适当地清理和整理它，以便找到您正在寻找的东西。
无论您选择如何定义它，认识到核心概念的重要性是降低风险的最佳起点。这意味着磨练承认与源代码相关的问题对生产力产生负面影响这一事实的能力，并制定解决该影响的计划。
技术债务的技术性
技术债务并不是包罗万象的。一个重要的区别是技术债务不包括您故意不构建的任何特性或功能。（也许，例如，一个特性最初是有范围的，但后来随着截止日期的改变而被废弃。）
相反，当 IT 出于各种原因选择延迟更好的编码和构建本应存在的内部部件时，就会产生债务。但这种忽略某些部分的选择被理解为如果不这样做将阻碍未来的开发和交付——如果团队不回头解决平庸的代码或解决已知的错误，结果就是累积的兴趣。
虽然技术债务可以指软件开发的任何部分，但它通常与极限编程相关，尤其是代码重构。重构是作为开发过程的一部分对现有代码进行重组，而不改变代码的外部行为（例如，重构一段写得不好的代码，它采用任何数字并将其乘以二仍然会输出 2 x 2 = 4，即使在底层代码已被重写）。
开发人员进行重构的两个主要原因是：
- 解决写得不好的遗留代码
- 随着问题得到更好的理解而优化解决方案
好与坏：技术债务的原因
就像金融债务一样，技术债务可能有充分的理由——但重要的是要知道进入技术债务，这样债务就不会领先于团队，从而减缓进度和未来的交付。
- 产生技术债务的一个很好的理由通常是因为交付比代码的内部整洁度或功能的流畅性更重要。如果产品对用户有用，尽管它不是最好或最整洁的产品，那么就上市时间、收入等方面而言，交付可能对贵公司有利。但是，如果业务需要完美的设计，您将花时间来提供更整洁的产品。
- 产生技术债务的一个糟糕原因是因为团队选择专注于其他更具创新性或更有趣但不那么重要的领域。
即使您有充分的理由承担债务，选择确保更快交付的更混乱的选项也不是该设计选择的终点。相反，团队必须在某个时候返回到该设计以添加更多功能或对其进行修改。团队等待处理问题的时间越长，它就越有可能导致更多问题或被埋没在代码中。这就是兴趣所在：将来您将不得不花时间清理它，让它适应您必须做出的新更改。
开发团队必须保持平衡。查看问题的多个方面，以确定是否要承担技术债务或承担多少技术债务。
技术债务的类型
正如我们在上面看到的，技术债务是软件开发的正常结果——其中一些是有充分理由的。某些类型的技术债务比其他类型的更糟糕：
计划的技术债务
当组织在充分了解后果（风险和成本）的情况下做出产生某些技术债务的明智决定时，就会发生这种类型的技术债务。在计划的技术债务的情况下，在定义组织打算做出的妥协方面尽可能准确是至关重要的。
举个例子：“为了赶上 11 月的新发布截止日期，我们决定放弃在项目的最后三周编写单元测试。我们将在发布后编写这些测试。”
由于这些决定会随着时间的推移而迅速累积，因此必须保留它们的记录。这样做会增加技术债务得到解决和更快偿还的可能性。否则，它很快就会被遗忘，从长远来看可能会给组织造成巨大损失。
无意的技术债务
这是指由于以下原因而产生的计划外技术债务：
- 不良做法
- 对新的编码技术缺乏经验
- 推出问题
例如，最终包含许多错误的设计方法是无意的技术债务。这种类型的发生有时是由于组织内部沟通不畅或开发人员与运营团队之间不一致的直接结果。
不可避免的技术债
不可避免的债务是由于业务的变化和随着时间的推移提供更好的解决方案的技术进步而产生的。它通常发生在项目中期请求范围变更时，这会导致直接成本，例如向现有设计添加新功能以更好地支持移动交付。
简而言之，当新的业务需求使旧代码过时时，就会产生技术债务。
软件熵
也称为比特腐烂，随着软件质量的缓慢恶化，软件熵会随着时间的推移而发生，从而导致可用性问题、错误或必要的更新。当许多开发人员（其中许多人可能不理解预期的功能和设计）进行增量更改以增加复杂性、违反 NFR 要求或慢慢破坏代码时，就会出现熵。
软件熵的解决方案是重构。
识别技术债务
以下是项目产生技术债务的一些警告信号：
- 代码坏味道比逻辑错误更微妙，并且表明问题更可能影响整体性能质量而不是导致崩溃。
- 当技术相互重叠时，复杂性更高。
- 将导致整个系统崩溃的产品错误。
- 编码风格问题，可以通过制定编码风格指南并坚持使用来解决。
- 代码违反 NFR 限制的非功能需求问题。示例包括性能低下、安全漏洞、不可靠的代码结果、越来越难以使用、与其他软件或硬件失去兼容性。
在这个阶段要注意的关键是，如果不加以解决，这些危险信号可能会导致：
- 总拥有成本更高
- 更长的上市时间
- 敏捷性降低
- 负面的客户体验
- 安全性差
非功能性需求 (NFR) 的核算
使用 Gartner 对技术债务的定义需要深入研究非功能性需求 (NFR)。了解这些非功能性需求对于识别技术债务很重要。每个系统都有 NFR，尽管它们通常没有定义或跟踪。NFR 是指对软件系统的约束，包括以下七个属性：
- 兼容性
- 安全
- 可靠性
- 可用性
- 效率
- 可维护性
- 可移植性
NFRs 还有一些重要的子特征：
- 明确的要求由主要利益相关者预定义，例如详细的设计规范。
- 隐含的要求是那些预期但没有明确说明的要求。一个例子是确保应用程序易于使用。
相比之下，功能需求概述了系统应该做什么，并且更容易测量和分析，例如在史诗的情况下。实现功能性和非功能性需求对于确保项目成功至关重要。
避免（太多）技术债务
虽然金融债务很容易追踪，但技术债务并不是天生的衡量标准。通过一些调整，技术债务理论可以转化为某些指标，例如上市时间与加班支付利息的时间。或者，它可能表现为团队生产力下降——这也很难衡量。
专家建议跟踪您的技术债务，以免它变得过于笨重。由于债务可以在多个开发周期中存活下来，因此跟踪和处理您的问题是必不可少的。这里有一个六步流程，用于消除垃圾和减少技术债务。
- 记录和追踪债务 - 记录所有开发人员认为存在问题的代码和设计
- 分类技术债务 - 将技术债务分门别类，并作为待完成工作任务。
- 评估技术债务影响 - 让所有人知道债务的影响并决定是否放入迭代中
- 公示技术债务 - 让技术债务公开透明
- 规划消除技术债务 - 跟利益相关者沟通技术债务的消除计划，告知可能因为要消除技术债务而影响新功能的交付。
- 尽早并经常消除技术债务 - 定期的安排技术债务消除
管理技术债务：最佳实践
这里有一些管理技术债务的方法。
评估债务
在识别技术债务时，您可能会遇到一些关键信号。例如，您的产品的性能评级可能正在下降，或者您的开发人员可能需要更长的时间进行迭代。但是你如何衡量呢？技术债务的真实成本是多少？
衡量这一点的一种方法是查看开发人员通过执行重构或替换应用程序等活动来减少技术债务所需的天数。一旦你为这些功能附加了金额，你就可以将这些数据与其他里程碑进行比较，比如发布日期前的剩余天数。这将提供出色的成本/收益分析，并有助于更有效地与组织的其他部门进行沟通。
除了提供当前状态更新之外，生成您对技术债务如何随时间变化的评估也很重要。
沟通债务
管理技术债务最重要的步骤之一是首先承认它的存在，并与主要利益相关者分享这一发现。IT 管理层应该负责定下基调并与非 IT 经理沟通技术债务的真实成本。IT 负责人还必须解释尽早偿还技术债务的重要性。
还清债务
在偿还技术债务方面，可以考虑三种选择：
- 完全放弃要求。换句话说，组织决定按原样使用系统，不再认为该要求是必要的。（如果你不能放弃这个要求，你只能选择另外两个选项……）
- 重构应用程序。此选项旨在降低复杂性、删除重复项并改进代码结构。重构是在不改变程序行为的情况下改进代码内部结构的唯一方法。
- 替换应用程序。虽然这会引入新的技术债务，但我们的想法是快速解决并尽可能减少它。
通过敏捷实践最大限度地减少技术债务
敏捷实践者知道“完成”是一个相对术语。在传统的开发环境中，软件在交付给用户时就完成了。但在敏捷环境中，工作的迭代经常交付给用户，改进每个版本中出现的错误和问题。没有“完成”。
敏捷依靠缩小发布范围来确保工作质量，而不是在发布中提交大量功能。
因为敏捷包含增量和迭代，而不是完成的项目，所以实施敏捷理论可能是控制技术债务的好方法。总是考虑短期的工作突发事件，这使 IT 团队更容易解决较小的技术债务组：持续不断。这样，就不会因为更大更好的项目和阶段而忘记债务，从而避免了长期利益。
为了减轻技术债务，使用测试自动化和持续集成 (CI)等敏捷方法可以确保您的 IT 团队始终致力于解决技术债务。每周冲刺也将允许敏捷团队清理数据和过时的假设。从长远来看，通过实施这些理论，许多人认为可以完全避免技术债务。
在新举措中减少债务
在新项目中减少技术债务的最好方法是尽早将技术债务包括在对话中。您将能够考虑短期决策对长期投资回报率的影响，并制定在项目开始时偿还债务的计划。
请记住，就像金融债务一样，技术债务持有的时间越长，其成本就会越高。通过最大限度地减少技术债务，您的团队可以降低风险、提高敏捷性并提供一流的结果。
原文：Technical Debt: The Ultimate Guide – BMC Software | Blogs
321
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
