技术债务对企业有巨大负面影响，而对于初创公司和大型企业来说，以下方法可以有效预防和管理技术债务。
技术债务这个概念似乎已司空见惯，几乎所有工程师都知道它会拖慢开发流程。因此，本文将提供一些实用建议，让工程团队无需在管理和解决技术债务方面耗费大量时间。
一、什么是技术债务?
通常，技术债务是指仓促的开发过程中或团队成员之间缺乏知识共享。但是，在许多情况下技术债务也是正常软件开发过程的一部分，而且不可避免。
比如，因为想节省时间来发布新的功能，工程师可能不会在基础架构中实施正确的设计模式。此外，不写文档共享知识或具有较低的代码测试覆盖率也是相关场景。
简而言之，代码质量会因各种方式受到影响，比如知识不共享或过于仓促的开发周期。下文概述了那些最具破坏力、也是人们最希望避免的技术债务类型：
- 基于知识的技术债务 为了理解基于知识的技术债务，先来看一个例子。想象一下，两名软件工程师正在开发一项新功能，他们拥有有关此特定功能的所有知识，但这些知识团队中的其他软件工程师却不具备。那么当其他软件工程师必须处理此功能或必须执行使用此功能的实现时，就会对正确实现新功能所需的知识一无所知。 因此，有关功能和重要代码库更改的知识必须积极共享，包括创建文档、示例、测试以及召开复盘会议。这也是解决技术债务最简单的方法之一。
- 设计债务 设计债务通常发生在竞争激烈的市场或初创公司，因为对于他们来说上市速度通常是重中之重。 由于要快速交付新功能，功能结构或代码架构就可能会被忽视。添加新功能也变得越来越困难，而你必须通过团队来解决。因此，设计债务也与结构化特征和遵守设计模式密切相关。 3.代码债务 代码债务是指所写代码质量差且未得到及时修复。例如开发人员希望快速合并代码，但没有编写足够的测试或未遵守代码标准。 许多组织使用像带有代码检查的预提交钩子等自动化工具来验证代码质量。如果你未实施这样的代码检查，糟糕的代码会迅速降低代码库的整体质量。
二、预防应对技术债务的三种推荐方法
技术债务日益累积，解决问题的最佳时机永远是当下。一些实用方法包括：
- 代码和架构重构 预防和/或解决代码和设计债务的最直接的解决方案之一是在每个X sprint组织一个重构周。重构周可让你的团队解决未处理的错误、评估当前架构并为即将推出的产品功能准备架构。 例如，留出一些时间来考虑新功能如何影响代码库的架构。 益处：重构周为开发人员在实现一组新功能之前评估和反思代码提供了所需的喘息空间，它非常适合解决大笔技术债务。 缺点：重构会拖慢开发过程，并且无法让团队持续解决技术债务。
- 开始定期的技术债务讨论 复盘会议是工程师分享知识的绝佳方式，这些会议甚至可以让更多的利益相关者参与(如产品所有者)，从而对代码库和工程师所面临的问题达成共识。 复盘会议将对顺利进展和不顺利进展共同讨论，这不是一个批评指责的活动，而是一个分享反馈的开放环节。只要专注于改进就是最好的。 益处：人们可以通过复盘会议来分享有关代码的更新，工程师可以展示他们所取得的成果。通常，工程师可以借此展示他们的代码库更改，并解释这些变化如何影响代码库以及他们实现这一点的方式。因此，召开复盘会议是每次编码冲刺后分享知识的有效途径。 缺点：利益相关者和管理者需要共同认可这一方式，且工程师也需要时间来组织这些会议。
- 开始在编辑器中跟踪技术债务 为了代码库保持健康，让工程师尽可能轻松地解决技术问题无疑是最佳方式。在编辑器中跟踪技术债务，工程师可以： 全面了解技术债务 查看每个代码库问题的上下文 减少上下文切换 持续解决技术债务 有多种工具可以跟踪技术债务，但最快速和最简单的入门方法是使用适用于VSCode或JetBrains的免费Stepsize扩展，它们可与Jira、Linear、Asana和其他项目管理工具集成。 益处：开发人员本就会有大量时间花在编辑器上，因此它也是跟踪和报告技术问题的最佳途径。实施技术债务管理流程将对工程师团队的士气带来积极影响，并提升客户满意度。 缺点：养成一个新习惯需要团队成员花时间花精力，且如果没有技术债务顶尖高手将很难实现。
三、如何检测不断增长的技术债务?
针对不同类型的技术债务应主动跟踪和管理，且不让技术债务增加是重点问题。 背负大量技术债务会大大拖慢开发速度，并让问题解决日益困难。换句话说，巨额技术债务代价高昂，并且会损害你的项目上线速度。 跟踪不同类型的技术债务相关的指标至关重要，以下指标可以跟踪： 总体代码覆盖率和每个功能的代码覆盖率：百分比下降是技术债务累加的危险信号。 许多失败的CI/CD构建数量：如果失败的CI/CD构建数量增加，就明显表示代码库不稳定。这点与设计债务和代码债务都有关。 每周或每月出现许多新bug：如果你的团队每周或每月发现越来越多的bug，则表明你的代码库质量下降。因此这点也是检测技术债务不断增长的重要指标。 特征吞吐量：将新功能推送到主分支需要的天数。这是一个支持指标，可以表明技术债务不断增长。虽然每个功能的大小不尽相同，但如果你发现这一指标数周内出现下降，就是时候进行干预了。 非功能性需求问题：在定义检测技术债务指标时，你是否考虑过衡量非功能性需求?衡量应用程序性能、用户体验(使用难度增加)或兼容性损失等指标是显示技术债务增加的可靠指标。如果你想使用此指标，可以尝试对应用程序中的关键路径进行性能监控。
四、不同阶段的公司如何以不同的方式处理科技债务?
对于初创公司来说，压力通常来自要快速发布产品。这些公司可以通过采用自动化代码质量验证工具轻松解决技术债务。除此之外，规模较小的团队之间积极分享知识通常也是避免技术债务的有效策略之一。 然而，大型企业要控制技术债务并非易事。根据2021年技术债务状况报告，66%的工程师认为，如果团队有一个管理技术债务的流程，交付速度将提高100%，另有15%的人甚至认为他们的生产力会提高200%。 遗憾的是，组织复盘会议等知识共享会议虽然也是解决方案之一，但大型企业往往需要一个比之更好的解决方案。 为了控制技术债务，大型企业需要使用项目管理工具来了解哪些功能正在开发，以及谁在处理代码库的特定领域，这些项目管理工具非常适合避免冲突。 除此之外，企业还应使用自动化代码质量工具来确保整体代码库健康，通常代码质量工具可以集成到持续集成管道中。
五、结论
不解决技术债务可能会给组织带来诸多问题，例如总拥有成本较高、上市时间拖慢、因架构设计不良而导致敏捷性降低和安全性差。 因此，必须衡量一些与技术债务相关的指标，同时要确保有一个特定流程，这样就可以轻松地与团队成员分享知识并持续解决技术债务问题。
