关于技术债务的这篇文章有一些优点，包括：

当故事驱动时，处理“技术问题”最有效。代码库可能在任何地方都需要工作，但是由于面向用户的原因，只有在要处理代码的地方才能收到回报。如果没有故事要经过某个棘手的领域，那么在这方面的工作就会被浪费掉。

因此，我更喜欢像往常一样拍摄故事（但可能更少），并遵循“童子军规则”，使故事比您发现的更好。换句话说，无论故事指引到哪里，让我们编写更多测试，让我们更积极地重构。

这种方法至少具有以下优点：

• 保持“最明智”的故事流；
• 提供所有团队人才的帮助；
• 让整个团队学习如何保持代码干净；
• 将改进的重点放在需要的地方；
• 不会浪费“可能”需要的改进；

我已经看到代码质量对长期生产力有很大的影响，所以我相信应该处理技术债务。我认为上面的帖子很有道理，但是我对最后两点不太确定。我有兴趣了解清除技术债务带来的收益的真实经验，即使这与用户故事无关。

通过清理代码库和消除技术债务，您看到了哪些积极的好处？您使用什么方法来完成工作？

我可以从我的经验中举一个例子。

大约10或12年前，我从一个开发人员团队继承了一个应用程序，该应用程序最终离开了公司（太久了，无法进入这里...）。该系统是一个大型的本地中间件报告生成系统。该报告每周晚上运行一次，为《财富》 500强公司的高级管理人员生成了约2打Excel报告。当我继承它时，它花费了大约5到6个小时才能运行，并且在任何给定的一周内至少会失败2个晚上。

我不是一个快乐的露营者，不会被这种混乱所困扰。

最初，我的计划只是停止流血并修复故障的主要原因。当我对代码库更加满意之后，我开始寻找可以重构并增加稳定性和性能的地方。在大约2年的时间里，我对系统进行了许多更改。几年前，我们淘汰了该系统，到那时，整个过程需要45分钟才能运行，并且多年来没有产生任何问题。

还清了很多工作，但是这是非常值得的。很高兴在半夜没接到电话，系统出现故障。很高兴来到公司的办公室，在日志中什么也没发现。

（在旁边。几年后，我遇到了这个系统的主要开发人员之一。他问我这是怎么做的，我告诉他该系统有多糟糕。他实际上道歉并告诉我，他知道这将会是他离开后希望自己能做得更好的情况下得到了极少数的支持）。

根据我的经验，当我必须维护尚未完成清理的代码时，代码清理的好处最为明显。在完成清理的地方，我的更改包括通读代码，发现需要更改的一两个位置，然后从那里开始。如果清理尚未完成，请添加第一步，以读取代码几次，然后尝试弄清楚作者（有时是我）在编写代码时的想法。

消除技术债务产生的技术支持更少，增强的基础更好

总是

我曾在前任雇主管理站点绩效团队时遇到过一次经历。在每天的一小时到两个小时的时间内，由于机器人迅速从该网站抓取信息，我的团队正在监视的网站会降至可接受的性能阈值以下。小组为解决此问题而采取的措施包括登录手动管理系统并阻止引起麻烦的IP地址。不用说，这几乎每天晚上都要花费团队成员一个小时的睡眠时间。我注意到发生了什么，我亲自花了几天时间打电话给黑莓手机，看看情况有多糟，并给我的团队一些休息。

几天后，我只是去找团队的业务负责人，让他们知道，如果我们不实施自动阻止系统，以至于僵尸程序将花费更多的时间来影响网站的性能，我们很可能会失败一些团队成员（如果不是全部）是由于疲劳和倦怠。他们同意了，我们实施了一个系统，使我们能够在晚上入睡。企业主了解，与雇用/培训新工程师的成本相比，几天或一周的开发成本很小。

关于最后两点：正如他的原始帖子所述，我了解它的来源：

或者，是否有可能重新分配一些开发人员来完成这些技术事务，而团队的其余成员则继续从事面向用户的工作？这可能会影响团队的速度，但那又如何呢？

“那么”等于：产品所有者和其他业务人员变得不高兴。当妈妈不开心时，每个人都会不开心。

然而，必须要做的事情和可能要做的事情之间的界限非常模糊。面向用户的范围非常广泛，包括性能和错误发生。但是在某些情况下，性能较差和错误发生率较高的根本问题在于代码中。用他的话说：一个故事可能不会穿过一个狭窄的区域，但是那个狭窄的区域可以隐藏一些讨厌的东西，这些东西在故事旁的清理路径上攻击了这个故事。

不会影响整体性能的事情在清理时不太有趣，但是应该非常仔细地评估这些点的影响。他们经常会产生相当大的间接影响。

一个组织因偿还技术债务而获得的最大利益就是避免了复利。下面的博客条目中有一个示例，该示例显示在短短的五年内，技术债务的本金如何从16万美元增加到43万美元。需要专职于偿还那笔债务的全职程序员。这将有助于决策者理解它！

来自blog.acrowire.com。