记录和计划技术债务？

Question

我已经在同一家软件公司工作了近14年。在这段时间里，我看到了大量的技术债务正在累积。我认为这对任何长寿的软件公司来说都是不可避免的。

然而，我们从来没有一个处理它的策略。我们知道技术债务，人们抱怨技术债务，但我们很少在我们的计划中建立任何方法来处理它。我知道这是人们离开我们公司的原因之一。

我做了一个搜索，但找不到任何有效的方法来处理技术债务？

我个人一直在做的是在我的repos中添加一个名为TechnicalDebt.md的文件，并描述我认为需要更改的内容和原因，以及对时间的估计。

以上是我的主要问题，但我希望对此有争议，尤其是那些声称“永远不应该有任何技术债务”的人。因此，您可以提供的任何东西，也使得有理由有一个方法的技术债务，将不胜感激。

Answer 1

我怀疑你的问题会因为太宽泛而关闭，这是一个遗憾，因为任何开发人员已经绕了几圈就会遇到很多这样的情况。

但是，为了分享我的经验-这方面有很多方面：

单元测试

偿还债务无疑将涉及到对遗留代码的重构。这一切都很好，但是如果你开始破坏事情，你很快就会成为不受欢迎的关注焦点。无论如何，一个好的单元测试套件应该已经就位，但是如果不是，那么就开始使用它吧，因为这些都会给您一个早期的警告，提示您的重构正在出错。

接近遗留代码

这是一个人们真正写书的主题--其中最著名的就是这里摘要。

债务的性质

并非所有的债务都是一样的--你如何处理它取决于债务的性质。如果它仅仅是一种过时的技术，那么它就可以简单地被替换，而不是重新分解。在不知道细节的情况下很难给出更多的建议。

收购

我曾在一些地方工作过，那里的管理都是关于特性和bug的，而且根本不愿意花时间去“抛光”。这当然是很短视的。如果你没有买到钱来解决这些问题，那么在代码中做其他事情的时候，你就必须去解决任何问题。

同时，你也要明白，这不仅仅是管理层的收购，你也需要你的同龄人的收购。对于如何解决各种问题，他们会有不同的看法。让每个人都参与，你会发现整个过程要容易得多。

你的仪式是什么？

有人说你永远不应该有技术债务。如果我可以这么说的话，这是一种相当天真的立场。也许他们的意思是，你的债务应该尽可能低(比如家庭债务)。

话虽如此，你有多少债务取决于你如何看待它。如果无论你在哪里都要还清债务，你就会发现它在急剧下降。如果你想在空闲时间(无论何时)修复它，这是一条漫长而艰难的道路--尤其是因为你可以在偿还另一笔债务所需的时间内积累更多的债务。

至于跟踪，首先，它应该被记录下来，它是你通常的工作跟踪工具。您如何将其与工作的其余部分分离开来，将因工具而异。

Answer 2

我发现跟踪技术债务的最好方法是在问题跟踪器中跟踪它，以及新特性/开发和bug。根据您正在使用的工具，可能有各种识别技术债务的选项，从发行类型到某种标记或标签。

总的来说，有两种方式来偿还技术债务。

首先，如果在正在开发的应用程序的相同领域存在技术债务，这应该反映在工作的估计中。如果存在大量的技术债务，则需要更长的时间才能将给定的功能开发到相同的质量水平。最低限度，估计数将说明需要通过技术债务进行工作，而且估计数可以包括偿还技术债务的努力。

第二，跟踪技术债务并偿还技术债务的单个工作项目对于规划和跟踪新开发之外的工作非常有用。如果目前或不久的将来，技术债务特性可能没有得到积极开发，这一点尤其有用。您可以跟踪系统更改的哪个区域(S)，以便跟踪和洞察测试工作的重点。

Answer 3

我认为这对任何长寿的软件公司来说都是不可避免的。

这就好比说，任何建筑物的衰败都是不可避免的。如果一幢建筑物从来没有维修过，那麽衰败是无可避免的。但是，如果你需要时间来做适当的维护，一座建筑几乎可以永远保持良好的状态。

同样，如果您需要时间来减少技术部门，代码库可能在产品的整个生命周期内保持良好的状态。

我做了一个搜索，但找不到任何有效的方法来处理技术债务？

许多软件公司提供了很好的例子。

你怎么找到那些公司的？通过观察成功的产品存在很长一段时间。虽然有些(如Windows)是从头开始重写的，但很多人没有:从头开始重写是一个昂贵而有风险的业务。经得起时间考验的著名产品之一是Linux.它的一个好处是它是开源的，所以您可以看到它是如何经过时间开发的，以及开发人员如何管理技术债务。

我希望对此有争议，尤其是那些声称“永远不应该有任何技术债务”的人。

在任何时候没有技术部门是相当昂贵的，而且并不总是有用的。虽然某些实践(例如重构)应该是一个常量活动，但其他一些可能会被推迟到代码足够稳定时。