测试驱动的技术债务减少

Question

假设你已经被指派负责一个已经存在的项目。当您开始熟悉存储库时，您会注意到一些技术债务问题(测试覆盖率不足、标准冲突、缺少文档等)。作为将要处理该项目并维护此代码的人，您可以将其添加到项目的待办事项中，目的是在几个版本中缓慢地减少它。

你们对这一技术债务的政策是：

• 这种技术债务可以通过单元测试来检测和衡量。
• 您希望使用单元测试来检测和度量这种技术债务，而不是依赖于人们可能错过的代码评审。
• 对于每一个发展，是可以接受的数额的技术债务保持不变或减少。技术债务的增加是不可接受的。
• 目前存在的技术债务预计将通过几次释放慢慢减少和消除。

(以上可能只适用于技术债务总额的一小部分，而不是全部；就本问题而言，我们只考虑上述情况属实的技术债务。)

我已经指出了一些方法，但它们也有缺点：

• 为代码的不同部分设置单元测试，这些部分将在清除技术债务时通过。这有一个缺点，在很长一段时间内，发布将不得不通过失败的单元测试来执行。
• 设置单元测试，如果技术债务低于某一阈值，将通过该测试。这样做的缺点是，如果技术债务水平降低，那么在门槛降低之前，更多的技术债务就有可能“溜进来”。
• 设置单元测试，但将代码的某些对象或部分白名单，以便测试始终通过白名单。这样做的缺点是，如果开发与白名单交互，即使开发使白名单对象更糟，测试也会通过。

在这种情况下，最好的办法是什么？

Answer 1

技术债务有多种形式，单位测试无法检测到。

例如：

• 用斯瓦希里语编写的API函数名。团队只会讲世界语。
• Codebase使用KORBA。没有人支持科尔巴。
• 承包商提供的串行化API工作完美，但没有遵循样式指南。

你可能在想，哦，等等，时尚指南！我们可以用静态分析工具检查是否符合。好吧，不。因为任何体面的风格指南都要求更多的东西，而不仅仅是插头上的绿灯。减轻技术债务是为了让人类快乐。不是CPU。

您可能会找到一些方法来自动化技术债务的测试。但你在很大程度上忽略了重点。与技术债务作斗争的最佳工具是代码评审。如果有人在订票时多走了一英里，而他们恰好把一些函数的名称改成了你能理解的东西，那就告诉他们谢谢。

如果您确实成功地构建了一套自动化的技术债务测试，请理解您所创建的也是代码。代码将有自己的技术债务。所以要小心你深入到这个兔子洞里去。

技术债务应始终被视为一种判断。没有完美的分数。已经够好了，还有“你还没说完吗？”

想想看，有一个技术债务的自动化测试，它提供了一个非常有用的度量标准，而不需要自己承担太多的债务。我已经用了好几年了。是这样的：

grep -r "//TODO" . | wc -l

Answer 2

这听起来很像SonarQube，它允许您为测试覆盖范围和自动检测的“代码气味”的数量设置策略。

SonarQube还可以与修订控制集成，这样它就可以判断一行是否是“新代码”。

这有一个缺点，在很长一段时间内，发布将不得不通过失败的单元测试来执行。

这通常被认为是非常糟糕的-你使“失败单元测试”信号无用，所以人们不得不检查每一次失败的细节。

设置单元测试，如果技术债务低于某一阈值，将通过单元测试。

这是一项务实的政策，可以让你完成任务。同时，每隔几个月设置一次重复事件，并检查号码。决定目标是什么，实现目标的速度，以及你能花多少时间来改进问题。

设置单元测试，但将代码的某些对象或部分白名单，以便测试始终通过白名单。

这可能是必要的，如果某些领域是特别糟糕的，无法修复，但同样，您可能想安排一个审查回来，修复问题，并删除白名单。

Answer 3

这个答案是对你的建议质量的一个框架的挑战，因为你内在地要求我们审查你提议的解决方案。

我只能推断，拟议的解决办法是幼稚的。这只是一个有教养的猜测，但你的想法让我想起了我和我的密友们在我们的开发人员职业生涯的初级和中级阶段之间提出的各种想法。

我说这番话的目的，是为了：

• 关于单元测试在某种程度上是技术债务的适当观察工具的断言(见其他人已经提出的评论)，以及在首先确认其正确性、可行性或特定范围之前，您使用了这个想法(您提到它可能不适用于所有债务，但在没有任何具体证据的情况下，我只能得出结论，这是您的假设，而不是您已经验证和识别的内容)。
• 没有考虑到将上述技术债务表示为“金额”的复杂性(您会使用什么单位？)
• 一个人可以以某种方式宣布并立即颁布这样一种观念，即技术债务应在选定的时间点停止--在此之前，技术债务一直是产生和忽视的。
• 对解决业务开发过程的任何意图的遗漏，这首先导致了技术债务。

技术债务本质上被定义为代码中的缺陷，而代码的行为并没有直接观察到这些缺陷，即附带的、有损于开发人员生活质量的问题。

如果需求从来没有规定过预期的性能水平，而当前的性能水平被认为是“操作但烦人”的话，人们可以认为性能问题是例外。

一旦您规定了什么是可接受的性能，并且要求开发人员在任何时候都遵守它，它就成了一个要求。

从语义上讲，这意味着不能满足这些要求可以进行测试(因为以前没有明确的量化)，但是任何失败都不再被视为技术债务--而是不符合验收标准。

您可能会发现这是一个没有意义的语义区分，但是当您的问题在谈论技术债务时，没有任何具体的债务实例；读者不可能推断您所关注的是哪种债务，以及它是否已经(或可以成为)您具体需求的一部分。

撇开上面关于性能测试的例子不谈，我觉得您当前的方法存在相当大的漏洞，这会降低您将付出的努力所带来的价值。

技术债务通常是由于业务流程缺陷而产生的。也许开发人员没有足够的经验，缺乏一位导师。也许公司设定的期限太紧了。也许主管人员会积极否定良好做法准则的有效性。

不管是什么原因，这是一个失败的人类过程，如果您只专注于处理结果(即代码质量)，而不是其根源所在的业务缺陷，那么您就是在治疗症状，而不是疾病。

在开发经理的角色中，我不会对您当前的建议给予太大的重视。它完全建立在有争议的断言(单元测试可以度量技术债务)、缺乏先见之明(将技术债务表示为金额的复杂性)或缺乏根源分析(首先导致问题的业务流程)的基础上。