技术债务报告

Question

我被要求创建一份关于应用程序的技术债务的报告，但是我还没有收到关于它的详细说明的进一步指导。我会得到声纳代码分析工具的帮助。

我的主要疑问是:在报告中列入哪些领域是有用的？我的意思是，在这样的报告中，什么指标、参数、发现、建议等才是最重要的？

Answer 1

当有人要求我做一些事情，而我对他们想要什么有疑问时，我就回去问他们。这是得到答案的最直接的方法。

作为一名经理，我希望这些领域：

• 描述，即问题是什么?为什么是问题？
• 未固定的风险金额
• 普遍性
• 要修复的工作级别，包括测试工作
• 相关的bug编号(如果有的话)

还请注意，正如我听说过的术语，技术债务是代码分析器将为您识别的一组问题的更广泛的领域。

Answer 2

除了用户246‘S的建议外，我还建议查看以下几个方面：

• 单元测试的存在/缺席
• 单元测试的有效性(也就是说，单元测试覆盖的范围是否超过了代码路径--它们也应该覆盖所有潜在的逻辑边界)
• 存在/没有高级自动化测试(包括系统、API、GUI、集成.)
• 更高级别自动化测试的有效性和覆盖范围与单元测试一样，这不仅仅是更高级别的自动化测试涵盖了多少代码库。
• 应用程序中客户报告的bug集群的区域--这不会被代码分析器找到，但它通常是一个很好的指针，指向应用程序中技术债务水平较高的区域。

我还第二次提到与经理/领导交谈的重要性，以了解更多他们想在报告中看到的内容。你有一个非常广泛的任务:你的经理可能需要一个详细的分析，或者他们可能正在寻找一个缩略图指南，他们需要集中改进的努力。

无论如何，我强烈建议与开发人员和测试人员交谈--任何使用应用程序的人都会对问题所在有一个很好的了解。根据我的经验，应用程序中的问题区域是技术债务最大的领域。

Answer 3

SonarQube是识别常见技术债务的一个步骤，比如代码气味或代码复杂性、重复代码和缺乏测试覆盖率。

第二步就像Kate建议的那样，让开发人员知道他们在哪里使用快捷方式、构建快速黑客或者代码中不可维护的部分是什么。

日志技术-债务并使其透明：

我们队的墙上有一张技术债务清单。它包含了清理待办的代码，从从测试代码中移除睡眠，升级库，还重构一个类，因为它很难理解。如果你的团队不记录技术债务，我建议你也开始创造意识。光靠SonarQube是不够的。

企业应该对未来需要解决的技术问题有一个公平的看法。如果您的业务依赖于它，那么发布快速生成里程碑(音调、演示、合同)的特性是很好的，但始终要注意这将在长期内产生什么样的效果。你会越来越慢，如果你的团队从一个黑客到另一个黑客，让狗屎做得太快。

如果您是敏捷团队，则将技术债务添加到待办事项中，以使其可见和透明。只有与缺陷相似，我会建议一项零技术债务政策。

全文如下：

• https://www.atlassian.com/agile/technical-debt
• https://martinfowler.com/bliki/TechnicalDebt.html