Project management 如何说服经理让你偿还技术债务？

虽然最近的一次并不是我第一次听说这个概念，但当我读到它时，我忍不住将它应用到我自己的项目中

我正在从事的代码库是一个正在进行的项目，大约在3年的时间内，项目早期的大部分代码都是由开发人员编写的，这些程序的性能很差，导致代码重复、性能不佳。等等。在与管理层的讨论中，我试图说明有几个关键组件迫切需要重构，这样做可以在未来的迭代中节省大量时间和麻烦，在这些关键领域添加新功能和修复bug。虽然他们似乎相信我重构这些组件会很好，但他们不想给我这样做的余地。请注意，我不是说重写整个代码库或任何戏剧性的事情，只是重写几个核心领域，大约需要2-3周的时间

---

接下来的问题是，作为一名开发人员，您如何向您的经理推销这些领域需要解决的问题，并制定一个商业案例，以便现在就有时间解决这些问题，而不必只是在这里或那里逐步改进？

您链接中的主要文章已经有了完美的答案。技术债务的描述非常好：

技术债务是一个极好的比喻 由Ward Cunningham开发以帮助 让我们思考这个问题。在这个 比喻，做事快，做事快 肮脏的方式给我们带来了技术上的麻烦 债务，类似于金融工具 债务。就像金融债务一样 技术债务产生利息 付款方式为 我们在这方面必须付出的额外努力 未来的发展是因为 快速和肮脏的设计选择。我们可以 选择继续支付 利息，或者我们可以付定金 通过重构 肮脏的设计变成更好的设计。 虽然支付预付款要花很多钱 本金，我们从减少利息中获益 未来的付款

这个比喻也解释了为什么它可能 明智地做那些又快又脏的事 方法就像一个企业发生的那样 一些债务可以利用 市场机会开发商可能 承担技术债务以达到目标 重要的最后期限。这种情况太普遍了 问题在于发展 组织让他们的债务转嫁出去 控制和花费他们的大部分时间 未来的发展努力 沉重的利息支付

如果项目要去任何地方，项目经理必须首先关心它。如果他关心自己的项目，光是这一描述就足以让他看到他可能从未想过的想法。只要帮助他建立一种方法来管理代码库中所有需要改进的地方。可能是问题跟踪系统中的团体或家长票证。这样，您就可以承担责任，并列出需要改进的地方。

答案总是“给我钱”，例如，为您提出的解决方案展示一个商业案例。传统上，这将通过计算与不合标准代码相关的服务任务或服务台票据来完成。您的具体案例将很困难，因为您所说的项目似乎不是在生产中

---

基于您所写的内容以及您的项目仍在开发中的事实，我要提醒您记住一句格言“更好是完成的敌人”。（我相信这句格言是由Michael Lopp创造的，或者至少是由Michael Lopp推广的。）在项目生命周期中，重构代码的时间可能会更好。

如果管理层有同情心，但是他们不愿意给你2-3周的时间来做一次彻底的检修，那么折衷的办法就是当你修复这些组件中的错误，编写一些测试和进行一些有限的重构，并随着时间的推移改进代码时

您可以这样做，或者您可以要求将10%添加到这些领域中用于此目的的bug/功能的估计值中。

作为一名经理，我愿意为三个具体业务案例之一进行代码重构/重写：减少技术支持、添加新功能和提高安全性

作为一名开发人员，我看到另外两个“接近”的情况，我将重构/偿还债务。你可能会发现你的经理对这些都很开放，或者他可能只是给你“那种眼神”，告诉你他不太相信

首先，有时候仅仅为了提高添加新功能的能力而进行重构是有意义的。例如，如果您可以看到业务即将到来，这将要求您的系统更加灵活和适应性更强，那么您可能需要重新考虑一些原始体系结构的承诺。这是偿还债务的大好时机

---

第二，当编写与已经存在的组件相关的新代码时，偿还一些债务是有意义的。例如，如果您添加的新类在逻辑上是现有类的兄弟类，那么将公共代码重构到父类中是有意义的。当您这样做时，您也有一个很好的机会来偿还债务。

在我的拙见中，每次提交代码时，您都应该小心谨慎地偿还技术债务，而不是每年花两三周的时间

小规模的持续改进最终会创造奇迹

无需请求许可即可。：-）

---

/罗杰

该项目已投入生产，但我们正在定期（我大概每季度发布一次）的版本中添加功能并修复bug，这意味着在qa开始之前，我们每个版本都会获得约150万的开发人员。我想说的是，我们将这些关键组件添加到循环中，目前还没有人同意我的观点。这个问题是离题的，因为它不在本网站的范围内，定义见：你可能可以问，或者。苏尔