技术债务揭秘

在此之前，我们将回顾什么是技术债务，什么不是，如何管理它，以及如何以负责任的方式偿还它。

照片由 Alice Pasqual 在 Unsplash上拍摄

介绍

我们在快节奏的工作环境中生活和工作。频繁的业务和组织变革、激烈的竞争以及创造产品和服务以满足客户需求和增加收入的压力。

这些条件产生了现代软件开发和交付实践，其中术语“敏捷”和“连续”是我们日复一日所做工作的各个方面的基础。

不可避免地，这种提高生产力和敏捷性的需求是如此重要和耗时，以至于我们几乎没有时间以可持续的方式正确规划和实施软件工程最佳实践。

诸如 MVP（最小可行产品）和 MVA（最小可行架构）之类的概念变得无处不在，并证明做最少的工作是合理的，以使软件或服务“出厂”。

我曾在许多小公司和大企业工作过，我记得在每个大企业中，我都参与或领导了一项重大的重构工作、彻底的系统重写或“打破单体”的工作。在某些时候，将其添加到简历中并获得有吸引力的工作机会几乎就像是一种时尚或魔法技能。

为什么会这样？

在大多数情况下，情况几乎相同：

开发从“薄弱”的基础开始，继续进行圆角，出于当时似乎合理的任何原因而忽略了非功能性需求，并且随着系统随着时间的推移，它迅速从看似成功的项目变成了一个遗留的怪物，没有一个人想要“触摸”或维护。

目睹如此多的公司突然意识到开发强大、高质量的系统是困难的，这令人着迷。

在某些时候，它会使这些公司陷入众所周知的恶性循环：开发速度放缓，错过最后期限，客户感到不安，工程团队承受的压力更大，这使得降低效率或迁移变得更加困难从传统到现代建筑。

在这种情况下，技术债务会迅速增加，从而导致工程生产力下降并给组织带来巨大成本。

定义的技术债务

让我们先从症状开始：

• 你是否觉得你的开发团队的生产力不是最好的

• 在决定将更改合并到代码库中之前，您是否三思而后行？

• 您的团队是否感到沮丧并不断与火拼？

如果您对所有这些问题的回答都是“是”，那么您可能正背负着严重的技术债务。

技术债务一词是 Ward Cunningham 在 1992 年创造的一个比喻。

坎宁安说：

当有意识或无意识地做出错误或次优的技术决策时，就会产生技术债务。

通过这个术语，Cunningham 希望找到一种方法来传达交付速度与持续改进正在开发的软件的架构和质量属性所需的努力之间的平衡。

类比来自金融债务，你有本金和利息。

与金融一样，您希望减少随着时间的推移会降低持续支付利息的原则。

与金融一样，利息是您每次需要在相关领域进行更改时因债务而付出的额外努力。

令人惊奇的是，这个类比很快就变成了自我实现的预言：如今，许多公司意识到技术债务已经开始显现出真正的财务影响，削弱了他们留住现有客户、获得新业务、提供有竞争力的解决方案的能力，最终当天，对公司的经营业绩产生了负面影响。

另一方面，技术债务的概念已经发展到开发人员明白他们需要一种明确定义的方法来识别其来源和管理它的策略，平衡短期目标和创造可持续发展的需要。产品长期可行。

灌输到 DevOps 实践中的静态代码分析工具可以更轻松地在潜在的质量和安全问题成为债务之前发现它们并实施持续的债务减免流程。

技术债务的类型

我认为，技术债务与糟糕的系统设计和缺乏对软件开发生命周期中要完成的架构工作的持续投资密切相关。

这一假设的推论是，即使在没有明确代码质量问题的系统中也可能存在技术债务。这意味着从理论上讲，您可以拥有一个运行良好的系统，并且仍然积累了需要您注意的债务。

为什么？因为我们都去过那里。智者说，变化是唯一不变的。

即使在某个时候您已经划清界限并决定将您的遗留系统置于维护模式并从头开始创建一个更好的版本，您仍然需要修改该遗留系统以满足现有客户的需求。

在这里你去：你将面对一个怪物，每次你触摸它都会“咬”你。

让我们回到我之前提到的系统设计和架构问题。

在他著名的文章《谁需要建筑师？” Martin Fowler 声称架构师最重要的任务之一是通过寻找消除软件设计中不可逆性的方法来消除架构。

没有理论上的理由可以说明软件中的任何事情都是不可逆的，而这就是技术债务的全部意义所在。

这是在对我们具有发展能力具有战略意义的地方缺乏投资。

使某些东西易于更改会使整个系统变得更加复杂，而使所有东西都易于更改会使整个系统变得非常复杂。

这就是为什么我们需要建筑师。

我们需要他们成为软件开发过程中不可或缺的一部分，以不断评估和提出以下问题：

我们应该关注哪些技术债务？

我们预计会改变哪些软件方面？

我们应该改进什么，以便改变更容易融入和管理？

技术债务的来源

在本节中，我们将回顾技术债务的主要来源：

人们

不出所料，人为因素是技术债务积累的最主要因素之一。

在技术方面，人们要么倾向于过度设计解决方案，专注于想象的用例，并在依赖错误假设的同时尝试优化，要么只是没有足够的经验来意识到他们做出的决策的缺陷和影响。在开发过程中制作。

意外复杂性是由上述原因引起的众所周知的现象之一。

导致意外复杂性的另一个相对较新的原因是所谓的“简历驱动开发”，其中技术和开发主管根据“时尚”或“酷”技术做出决策，以获取由于稀缺而具有高需求的技能。

在业务方面，人们并不总是意识到一些早期设计决策可能对软件项目产生的影响以及他们可能在未来产生的成本。

过程

从流程的角度来看，让我们从应该有流程的断言开始。

减少技术债务首先需要 (i) 识别其中的具体项目，(ii) 评估它们对可预见的软件演进的影响，(iii) 了解债务成本，以及 (iv) 最后引入将其影响传达给相关技术和业务的机制利益相关者（例如开发负责人和产品经理/所有者），以便他们计划减少它。

技术

有时，尽管尽了最大的努力和意图，我们很快就会以过时或有限的技术告终，这些技术无法应对规模、性能、维护或任何其他需求以及内部和外部的力量。

如果发现和替换较晚，它会导致变通办法和补丁、快速而肮脏的解决方案（以“创意”的名义销售），并最终导致产品复杂性的增加。

产品

产品经理不可避免地遇到的主要矛盾之一是功能开发与在设计、最佳实践实施和技术债务减少方面投入开发时间之间的关系。开发人员希望提高他们开发的系统的质量、性能和稳定性，而不是包含更多面向客户的功能和改进。

当我们处理“范围蔓延”时，情况要糟糕得多。

除了少数例外，我们在产品中增加的每平方英寸表面积都会增加其复杂性并降低我们快速移动的能力。

提供新功能需要考虑成本。这反过来意味着产品经理不仅应该关心“什么”，还应该关心“如何”，因为它可能有助于推动更好的决策，以平衡短期结果和长期软件可持续性。

偿还技术债务

解决技术债务并非易事。

正如我们之前看到的，它从认识它开始，然后了解它的类型，然后与相关利益相关者进行量化和沟通，然后制定一个行动计划来实施它的减少。

根据我的经验，最具挑战性的部分是让所有相关决策者相信必须这样做。

必须这样做，因为只有在经济上可行的情况下，软件开发才能作为一个行业持续存在。

结论

市场和客户不断要求新的应用程序和系统——他们现在就需要它们。

其中一些应用程序将是短暂的，但一些，通常是成功的应用程序，必须长期维护和扩展。

技术债务是创建可持续软件的最大障碍，管理它应该解决我们如何应对快速扩展的软件基础的问题，同时保持它的可扩展性、高性能、安全性、运行在最新技术之上，并以经济可行的方式实现其业务和用户目标。

我们看到，它始于意识到由于缺乏专业知识、相互冲突的优先级、缺少流程和许多其他原因，不断发展的软件将积累技术债务。

显然，管理技术债务需要技术方和业务方的关注和纪律，但如果我们都同意未能管理它最终会导致我们自己的挫败感和影响整个组织的糟糕业务结果，我们可以进行协作努力以负责任的方式计划和处理它。