如何说服经理让你偿还技术债务？ [关闭]答案

【问题标题】：How to convince a manager to let you pay down technical debt? [closed]如何说服经理让你偿还技术债务？ [关闭]
【发布时间】：2009-03-01 18:13:58
【问题描述】：

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

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

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

【问题讨论】：

这个问题是题外话，因为它不在本网站的范围内，如What topics can I ask about here? 中定义的那样另见：What types of questions should I avoid asking? 您可以在another Stack Exchange site 上提问，也许 Project Management 或Software Engineering。请务必阅读您打算发布问题的任何网站的帮助中心主题页面。

标签： project-management technical-debt

【解决方案1】：

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

作为一名开发人员，我看到了另外两个“近在咫尺”的案例，我将重构/偿还债务。你可能会发现你的经理对这些持开放态度，或者他可能只是给你“那种表情”，告诉你他不太买账。

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

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

【讨论】：

【解决方案2】：

一如既往，答案是“给我钱”，例如 - 为您提出的解决方案展示一个商业案例。传统上，这将通过计算与不合格代码相关的服务任务或帮助台票来完成。您的具体案例将很困难，因为您似乎在谈论一个未投入生产的项目。

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

【讨论】：

该项目处于生产阶段，但我们正在通过定期（我大约每季度一次）发布来添加功能和修复错误，这意味着对于每个发布，我们在 qa 开始之前获得约 1.5 mnths 的开发。我试图争辩的是，我们在循环中添加了这些关键组件的重建，目前还没有人同意我的观点。

【解决方案3】：

如果管理层表示同情，但不愿给您 2 到 3 周的时间进行全面检修，那么折衷方案是当您修复这些组件中的错误、编写一些测试并进行一些有限的重构等时时间改进代码。

您可以直接这样做，或者您可以要求将 10% 添加到用于该目的的那些区域中的错误/功能估计值中。

【讨论】：

【解决方案4】：

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

技术债务是一个绝妙的比喻由 Ward Cunningham 开发以帮助我们思考这个问题。在这个比喻做事快而快肮脏的方式为我们设置了技术债务，类似于金融债务。就像金融债务一样，技术债务产生利息付款方式为我们必须付出的额外努力未来的发展因为快速而肮脏的设计选择。我们可以选择继续支付利息，或者我们可以偿还主要通过重构快速和肮脏的设计变成更好的设计。虽然要付出代价本金，我们通过减少利息获得将来付款。

这个比喻也解释了为什么它可能明智地做快速和肮脏的事情方法。就像企业招致一些债务以利用市场机会开发商可能招致技术债务打击重要期限。太常见了问题是发展组织让他们的债务摆脱控制和花费他们的大部分未来发展努力付出严重的利息支付。

如果项目要去任何地方，项目经理必须从一开始就关心它。如果他关心他的项目，那么仅此描述就足以让他看到他可能从未想过的想法。只需帮助他设置一种方法来管理代码库中需要改进的所有地方。可能是您的问题跟踪系统中的组票或父票。这样你就可以有责任感并列出需要改进的地方。

【讨论】：

【解决方案5】：

以我的拙见，每次提交代码时都应该以少量的方式偿还技术债务，而不是每年花两三周的时间来完成。

小块的持续改进最终会创造奇迹。

那么不需要请求许可。 :-)

/罗杰

【讨论】：