shs*_*mer 13 project-management technical-debt
虽然最近的Coding Horror博客文章并不是我第一次听到这个概念,但正如我在阅读它时,我忍不住将它应用到我自己的项目中.
我正在处理的代码库是一个正在进行的项目,大约在3年的时间里,项目早期阶段的大部分代码都是由开发人员编写的,这些开发人员的监督很少,导致很多代码重复,性能不佳等.在与管理层的讨论中,我试图证明有几个关键组件需要重构,这样做会在添加新功能时节省大量时间和麻烦.并修复这些关键领域的错误.虽然他们似乎相信我重构这些组件会很好,但他们不想给我这样做的余地.请注意,我不是在谈论重写整个代码库或任何戏剧性的内容,而只是重写一些需要2-3周的核心领域.
那么问题是,作为开发人员,如何向您的经理出售这些领域需要解决的问题并制定业务案例以便现在有时间解决这些问题,而不是仅仅在这里和那里逐步改进？
作为经理,我愿意为三个具体业务案例中的一个进行代码重构/重写:减少技术支持,添加新功能和提高安全性.
作为开发人员,我看到另外两个"近距离"案例,我将重构/偿还债务.您可能会发现您的经理对这些人持开放态度,或者他可能只是给您"看起来",告诉您他并不完全购买它.
首先,有时候重构只是为了提高你添加新功能的能力.例如,如果您可以看到将要求您的系统更灵活和适应性更强的业务,那么您可能需要重新考虑一些原始架构的承诺.这是偿还债务的好时机.
其次,当编写与已经存在的组件相关的新代码时,偿还一些债务是有意义的.例如,如果您要添加一个逻辑上是现有类的兄弟类的新类,那么将公共代码重构为父类是有意义的.当你这样做时,你也有很好的机会偿还债务.
您链接中的主要文章已经有了完美的答案。对于技术债务的描述非常好：
技术债务是沃德·坎宁安为帮助我们思考这个问题而提出的一个绝妙的比喻。在这个比喻中，以快速而肮脏的方式做事会给我们带来技术债务，这类似于金融债务。就像金融债务一样，技术债务也会产生利息，而利息的形式是我们在未来的开发中由于快速而肮脏的设计选择而必须付出的额外努力。我们可以选择继续支付利息，也可以通过将快速而肮脏的设计重构为更好的设计来偿还本金。尽管偿还本金需要付出一定的成本，但我们可以通过减少未来支付的利息来获益。
这个比喻还解释了为什么采取快速而肮脏的方法可能是明智的。正如企业为了利用市场机会而承担一些债务一样，开发商也可能为了赶上重要的最后期限而承担技术债务。最常见的问题是，开发组织让债务失控，并将未来的大部分开发努力用于支付巨额利息。
如果项目要去任何地方，项目经理必须首先关心它。如果他关心他的项目，那么仅这个描述就足以让他看到他可能从未想到过的想法。只需帮助他建立一种方法来管理记录代码库中需要改进的所有地方即可。也许是您的问题跟踪系统中的团体或家长票证。这样你就可以承担责任并列出需要改进的地方。