虽然最近的Coding Horror博客文章并不是我第一次听到这个概念,但正如我在阅读它时,我忍不住将它应用到我自己的项目中.
我正在处理的代码库是一个正在进行的项目,大约在3年的时间里,项目早期阶段的大部分代码都是由开发人员编写的,这些开发人员的监督很少,导致很多代码重复,性能不佳等.在与管理层的讨论中,我试图证明有几个关键组件需要重构,这样做会在添加新功能时节省大量时间和麻烦.并修复这些关键领域的错误.虽然他们似乎相信我重构这些组件会很好,但他们不想给我这样做的余地.请注意,我不是在谈论重写整个代码库或任何戏剧性的内容,而只是重写一些需要2-3周的核心领域.
那么问题是,作为开发人员,如何向您的经理出售这些领域需要解决的问题并制定业务案例以便现在有时间解决这些问题,而不是仅仅在这里和那里逐步改进？
作为经理,我愿意为三个具体业务案例中的一个进行代码重构/重写:减少技术支持,添加新功能和提高安全性.
作为开发人员,我看到另外两个"近距离"案例,我将重构/偿还债务.您可能会发现您的经理对这些人持开放态度,或者他可能只是给您"看起来",告诉您他并不完全购买它.
首先,有时候重构只是为了提高你添加新功能的能力.例如,如果您可以看到将要求您的系统更灵活和适应性更强的业务,那么您可能需要重新考虑一些原始架构的承诺.这是偿还债务的好时机.
其次,当编写与已经存在的组件相关的新代码时,偿还一些债务是有意义的.例如,如果您要添加一个逻辑上是现有类的兄弟类的新类,那么将公共代码重构为父类是有意义的.当你这样做时,你也有很好的机会偿还债务.
京公网安备 11010802040832号 | 京ICP备19059560号-6 