虽然最近的Coding Horror blog entry并不是我第一次听说这个概念，但正如我在阅读它时，我忍不住将它应用到我自己的项目中。
我正在开发的代码库是一个正在进行的项目，大约在3年的时间里，项目早期阶段的大部分代码都是由开发人员编写的，这些开发人员的监督很少，导致很多代码重复，性能不佳等等。在与管理层的讨论中，我试图证明有几个关键组件需要重构，这样做会在以后的迭代中节省大量的时间和麻烦。添加新功能并修复这些关键区域中的错误。虽然他们似乎相信我重构这些组件会很好，但他们不想给我这样做的余地。请注意，我不是在谈论重写整个代码库或任何戏剧性的内容，而只是重写一些需要2-3周的核心领域。
接下来的问题是，作为一名开发人员，如何向您的经理出售这些领域需要解决并制定商业案例以便现在有时间解决这些问题，而不是仅仅在这里和那里逐步改进？
答案 0 :(得分：8)
作为经理，我愿意为三个具体业务案例中的一个进行代码重构/重写：减少技术支持，添加新功能以及提高安全性。
作为开发者，我看到另外两个“近距离”案例，我将重构/偿还债务。您可能会发现您的经理对这些人持开放态度，或者他可能只是给您“看起来”，告诉您他并不会购买它。
首先，有时候重构只是为了提高你的能力来添加新功能。例如，如果您可以看到将要求您的系统更灵活和适应性更强的业务，那么您可能需要重新考虑一些原始架构的承诺。这是偿还债务的好时机。
其次，当编写与已经存在的组件相关的新代码时，偿还一些债务是有意义的。例如，如果您要添加一个逻辑上是现有类的兄弟类的新类，那么将公共代码重构为父类是有意义的。当你这样做时，你也有很好的机会偿还债务。
答案 1 :(得分：3)
答案一如既往地是“告诉我钱”，例如 - 显示您提出的解决方案的商业案例。传统上，这可以通过计算与不合标准代码相关的服务任务或帮助台票证来完成。您的具体案例将很难，因为您似乎在谈论的是未投入生产的项目。
根据您所写的内容以及您的项目仍处于开发阶段的事实，我会提醒您记住“更好是完成的敌人”的格言。 （我相信它是由Michael Lopp创造或至少推广的。）在项目生命周期中可能有更好的时间来重构代码。
答案 2 :(得分：3)
如果管理层有同情心，但他们不愿意给你2-3个星期进行全面检修，那么当你修复这些组件中的错误，编写一些测试并做一些有限的重构时，就会妥协。时间改善了代码。
您可以这样做，或者您可以要求将10％添加到用于此目的的那些区域中的错误/功能的估计值中。
答案 3 :(得分：2)
您链接中的主要文章已经有了完美答案。这种对技术债务的描述非常好：
技术债务是一个很好的比喻 由Ward Cunningham开发帮助 我们想想这个问题。在这 比喻，快速做事 肮脏的方式为我们提供了技术支持 债务，类似于金融 债务。就像金融债一样 技术债务产生利息 付款，以形式出现 我们必须做的额外努力 未来的发展因为 快速而肮脏的设计选择。我们可以 选择继续支付 兴趣，或者我们可以付出代价 通过重构快速和 肮脏的设计融入更好的设计。 虽然付出代价是成本 校长，我们通过降低利息获得收益 未来的付款。
这个比喻也解释了为什么会这样 做得快而肮脏是明智的 做法。就像生意一样 一些债务利用a 市场机会开发商可能 招致技术债务 重要的截止日期。太常见了 问题在于发展 组织让他们的债务摆脱 控制和花费他们的大部分 支付未来的发展努力 瘫痪利息支付。
如果项目要去任何地方，项目经理必须首先关心它。如果他关心他的项目，那么这个描述就足以让他睁开眼睛看他可能从未想过的想法。只是帮助他设置一种方法来管理代码库中需要改进的所有地方。可能是问题跟踪系统中的组或父票证。这样，您就可以获得问责制以及需要改进的清单。
答案 4 :(得分：2)
我个人认为，每次提交代码时，你应该以少量的方式偿还你的技术债务，而不是每年抽两到三个星期。
小块的持续改进最终会创造奇迹。
然后无需征得许可。 ： - ）
/罗杰