酷应用

如何用技术债务提案助力解决技术债务？

百家作者：51CTO技术栈 2022-05-28 11:33:09

译者 | 朱钢

策划 | 武穆

本文将指导你完成制定技术债务提案，从而让解决技术问题所花费的时间更合理。

技术债务是拖慢技术团队生产力的元凶。起初技术债务似乎不是一个障碍，但随着时间的推移，它可能会阻碍团队的开发效率。在许多情况下，团队的工作会达到一个临界点，在这个临界点上，技术债务就会成为新功能得任何进展的阻碍因素。

本文将帮助你制定技术债务提案，以证明为了解决问题而花费一些时间是合理的，更重要的是防止技术债务。让我们来看看你应该在技术债务提案中包含哪些会帮助管理层做出决策的元素。

首先，让我们来探讨一下为什么需要写一个技术债务提案。

PART 01

为什么需要写一份技术债务提案？

有时候，你的管理层可能没有意识到正在减慢开发团队速度的技术问题。技术债务提案可以帮助你证明解决技术债务所花费的时间和资源是合理的，并制定计划以进一步防止技术债务。

为此，你需要收集证据并提出衡量成功的计划和指标。需要注意的是，你可能做出了错误的估计，因此解决方案不起任何作用。这意味着，你要能够跟踪技术债务提案的有效性，以便在未按预期进行时开始干预。

以下内容重点介绍指导你完成创建技术债务提案的不同步骤，包括如何确定工具以及如何围绕此工具构建计划。

步骤1：确定对技术债务中影响最大的问题

首先，确定对工程团队工作效率影响最大的技术债务问题。工程团队在问题跟踪或项目管理工具中徘徊时，通常会意识到这些问题。

识别这些问题的最佳方法是在编辑器中跟踪技术债务。在编辑器中跟踪技术债务可以使得工程师能够全面了解技术债务，查看每个代码库中问题的上下文，并减少上下文切换。

识别技术债务的一种方法是在VSCode或JetBrains中使用免费的Stepsize扩展，这些扩展与Jira、Linear、Asana和其他项目管理工具是集成在一起的。

这是开始收集代码库中的所有关键技术问题的快速方法。

步骤2：识别工具

不要低估使用适当的工具来管理技术债务的力量。一些技术团队可能没有使用任何工具，或者使用正确的工具或使用过时的工具。这些场景是合理的，在确定要包含在技术债务提案中的工具时需要考虑这些情况。

对于许多团队来说，实施正确的工具可以解决和防止大量的技术债务。但是，工程团队需要证明使用特定工具的成本的合理性。

选择工具时，你需要问自己以下问题：

哪种工具能提供最佳功能来解决团队的问题？
实施特定工具会有什么影响？
工具成本是多少，是否有更便宜的选择可以解决你的技术债务问题？某些工具需要特定设置，但是这些设置你的技术团队可能尚未准备好，或者工具需要自托管，这会带来额外费用。

一旦你认为你已经找到了合适的工具，请确保在你的技术债务提案中包含上述问题的摘要。此摘要将帮助CTO、团队主管和管理层更好地了解你选择特定工具的原因。

有很多工具可以帮助你处理技术债务，以下一些示例。

（1）持续集成（CI）工具，可以帮助团队保证其代码的质量。CI工具可以强制执行编码标准并执行复杂类型的测试，例如集成测试或端到端测试，以便为开发人员团队提供对其代码的信任。

（2）静态分析工具（如SonarQube），用于分析源代码以寻找技术债务。这些工具使用定量数据来帮助开发人员识别代码库中可能存在技术债务热点。不过它们也有局限性，比如，它们不会帮助你识别跨越代码库多个部分的中型到大型债务，也不会为你提供真正理解每一笔债务以及如何优先考虑并最终解决它所需的上下文。

（3）前端问题跟踪器工具 Stepsize ，可帮助技术团队跟踪编辑器中的技术债务，并将问题链接到代码。这些工具对持续跟踪和修复技术债务、提高编码标准、通过在编辑器中创建问题来减少上下文切换等都会有帮助。

步骤3：设置指标并定义基线

接下来，你需要定义指标来证明成本的合理性。指标允许你衡量技术债务提案的有效性，尤其是你选择的工具的有效性（例如，你选择的工具无法根据你正在测量的指标解决你的问题）。它允许你干预和重新调整你的技术债务提案，或寻找不同的工具来解决你的问题。

换句话说，拥有指标可能会让你避免在不正确工具上浪费大量的金钱。而且，添加不正确的工具会进一步增加技术债务，因为你的工程师必须学习他们不熟悉的新工具。下面是可以为持续集成示例定义指标的快速列表：

测试覆盖率百分比

与编码标准相关的问题数量

在生产环境中发现的错误数

软件工程团队的功能吞吐量

修复 Bug的平均时间

特别提示：不要忘记设置基线。如果没有基线，就无法确定你的技术债务提案的有效性。

步骤4：寻找解决技术债务的其他方法

虽然工具可以快速解决技术债务，但也要看看其他解决技术债务的方法。

通常，你可以将实现新工具的建议与其他计划，如重构周或实施新型会议（如回顾会议）相结合。

重构周为你的团队提供了所需的喘息空间，以重新评估代码库并确定他们想要解决的关键问题。除此之外，它可以用作重启实施新的工具以进一步减少团队的技术债务。

其他潜在的计划是分享会议，团队成员分享有关代码库的知识或教授其他团队成员有关新技术的知识。这完全取决于你的团队所经历的技术债务类型。

PART 02

结论：保持警惕！

一旦你的团队解决了技术债务，就不要让技术债务再次降临到团队身上。因此，请继续衡量你设置的指标。除此之外，你还可以创建一个计划来衡量其他指标，以更好地了解团队绩效以及技术债务的积累方式。简而言之，技术债务是一个令人讨厌的怪物，可以随时迅速回归。保持警惕！

参考链接：

https://dzone.com/articles/the-engineers-guide-to-creating-a-technical-debt-p

译者介绍

朱钢，51CTO社区编辑，2021年IT影响力专家博主，阿里云专家博主，2019年CSDN博客之星20强，2020年腾讯云+社区优秀作者，11年一线开发经验，曾参与猎头服务网站架构设计，企业智能客服以及大型电子政务系统开发，主导某大型央企内部防泄密和电子文档安全监控系统的建设，目前在北京图伽健康从事医疗软件研发工作。