虽然最近的Coding Horror 博客文章不是我第一次听说这个概念，但当我阅读它时，我忍不住将它应用到我自己的项目中。
我正在处理的代码库是一个正在进行的项目，现在大约有 3 年了，项目早期阶段的大部分代码是由开发人员编写的，他们几乎没有监督，这导致了很多代码重复、性能不佳等。在与管理层的讨论中，我试图说明有几个关键组件迫切需要重构，这样做可以在未来的迭代中节省大量时间和添加新功能时的麻烦并修复这些关键领域的错误。虽然他们似乎相信我重构这些组件会很好，但他们不想给我这样做的余地。请注意，我不是在谈论对整个代码库的重写或任何戏剧性的事情，只是对几个核心领域的重写，这将花费大约 2-3 周的时间。
那么问题来了，作为一名开发人员，您如何向您的经理推销这些领域需要解决的问题，并提出商业案例以便现在有时间解决这些问题，而不必只是在这里和那里逐步改进？
作为经理，我愿意为以下三个具体业务案例之一进行代码重构/重写：减少技术支持、添加新功能和提高安全性。
作为一名开发人员，我看到了另外两个“近在咫尺”的案例，我将重构/偿还债务。你可能会发现你的经理对这些持开放态度，或者他可能只是给你“那种表情”，告诉你他不太相信。
首先，有时仅仅为了提高添加新功能的能力而进行重构是有意义的。例如，如果您可以看到需要您的系统更加灵活和适应性更强的业务，那么您可能需要重新考虑一些原始架构的承诺。这是偿还债务的好时机。
其次，当正在编写与已经存在的组件相关的新代码时，偿还一些债务是有意义的。例如，如果您要添加一个新类，该类在逻辑上是现有类的兄弟类，那么将公共代码重构为父类是有意义的。当你这样做时，你也有一个很好的机会来偿还债务。
与往常一样，答案是“给我钱”，例如 - 为您提出的解决方案展示一个商业案例。传统上，这将通过计算与不合格代码相关的服务任务或帮助台票来完成。您的具体案例将很困难，因为您似乎在谈论一个不在生产中的项目。
仅基于您所写的内容以及您的项目仍在开发中的事实，我会提醒您记住格言“更好是完成的敌人”。（我相信它是由 Michael Lopp 创造或至少推广的。）在项目生命周期中可能会有更好的时间来重构代码。
如果管理层表示同情，但不愿给您 2-3 周的时间进行全面检修，那么折衷方案是修复这些组件中的错误，编写一些测试并进行一些有限的重构，然后随着时间的推移改进代码。
您可以这样做，或者您可以要求将 10% 添加到用于该目的的这些区域中的错误/功能的估计中。
您链接中的主要文章已经有了完美的答案。这个技术债的描述非常好：
技术债务是 Ward Cunningham 为帮助我们思考这个问题而提出的一个绝妙的比喻。在这个比喻中，快速而肮脏的做事方式给我们带来了技术债务，这类似于金融债务。就像金融债务一样，技术债务也会产生利息，这是由于快速而肮脏的设计选择，我们必须在未来的开发中付出额外努力的形式。我们可以选择继续支付利息，也可以通过将快速而肮脏的设计重构为更好的设计来偿还本金。尽管偿还本金需要付出代价，但我们会通过减少未来的利息支付来获得收益。
这个比喻还解释了为什么采取快速而肮脏的方法可能是明智的。就像企业为了利用市场机会而承担一些债务一样，开发人员可能会承担技术债务以赶上重要的最后期限。最普遍的问题是，发展组织让他们的债务失控，并将他们未来的大部分发展努力花在支付严重的利息上。
如果项目要去任何地方，项目经理必须从一开始就关心它。如果他关心他的项目，那么仅此描述就足以让他看到他可能从未想过的想法。只需帮助他设置一种方法来管理代码库中需要改进的所有地方。可能是您的问题跟踪系统中的组票或父票。这样，您就可以承担责任并列出需要改进的内容。
In my humble opinion, paying off on your technical debt is something you should do in small bits every time you submit code, not taking time off to do two or three weeks a year.
Continuous improvement in small chunks will work wonders in the end.
No need to ask for permission then. :-)
/Roger