假设我有一个较旧的系统/框架，它显示了它的年龄，但很快就会被利用来做比它最初打算做的更多的事情。它是一个没有很多常见代码隐藏的Web应用程序，因此我建议从长远来看，使用更具前瞻性的代码重建它会减少工时量，并着眼于减少维护工作（我已经拥有遗留系统一段时间了，并且相信这是真的）。请记住，遗留系统的体系结构最终需要进行大量的故障排除和TLC：我不关心它是否“漂亮”或“正确”写入它是否正常工作，但它并不“正常工作”现在就是这样。在成功使用类似系统之前，我已经完成了重写，如果我正确地提出它，它看起来像是对我开放的权力。
所以现在由我来推销这个想法。我之前提到的我成功改写的系统并不是正式的，而是一种在我的业余时间，但如果我在重写中花费一些前期时间，这会对项目时间表产生直接影响。这意味着我更了解我的东西。以前没有正式证明完全重写，我想知道如何推销它。
当然，我当然需要对重写进行范围调整，但在此之后它会模糊不清。在重写之后，有数字可以证明维护成本和节省，但这很难估计。还有什么吗？
答案 0 :(得分：3)
我成功地投了几次这个音调，这是我的总策略。这是基于我们的公司文化，在技术使用方面比我们的业务领域更先进，但我相信这些策略几乎可以在任何地方使用。
首先，您需要让他们了解公司的需求和经济利益。如果没有，请不要打扰。如果你能想出具体的数字，那就这样做吧。如果没有，请给出最佳估计，并告诉他们这是一个估计。如果这个数字是完全未知的，请尝试找出可能知道的人的数字。然后这是我使用的一般音高格式。
首先，我描述了该计划的作用以及它对我们公司的好处。指出它如何节省资金，或为您提供竞争优势。让他们看到这个系统对我们的成功至关重要。
其次，解决问题。描述问题如何影响业务，而不是它们如何影响您作为维护程序员。
确保包含任何最终用户的痛苦。 （例如，他们需要等待系统修复，他们的生产力下降，否则我们可能会错失机会。或者他们需要手动计算数字，这需要时间和浪费劳力。某事。）
如果你可以诚实地说，重写需要多长时间而不是让它离开，你需要证明你每个月每周/每周/每周花费x小时，这将需要这个很多时候重写。
如果重新编写的时间比您在故障排除上花费的时间长，请确保在出现问题时包括浪费的时间。
基本上，你需要考虑底线。底线不仅仅是金钱。它还提供了比竞争对手更好的机会（这就是公司首先在IT上花费的原因 - 跟上或者比其他人更好。）
修改
此外，不要打算包括升级可以带来的改进，以及它们如何为公司带来优势。
答案 1 :(得分：3)
谁在使用网络应用？得到他们对重写的支持，否则你可能会遇到麻烦，当事情没有完全解决时（“你为什么要改变它？现在它比以前更糟糕！”）一个好方法就是问他们想要什么等待修复。确保他们能够解决新系统的痛苦。
估计用当前系统修复错误需要多长时间，并将其放在估计数字旁边以重写它。说实话。
检查您过去花了多少小时来解决问题。明确表示你会把这个号码记下来。
确保您必须从头开始重写所有内容。通常，通过重构和大量单元测试逐位迁移现有代码更安全，更简单
如果您想避免独自遇到任何麻烦，请让贵公司的重要人员为此提供支持。寻找决策者，层级中较高层的人，声音有些重量的人。
答案 2 :(得分：2)
许多公司宁愿继续修补一些有效的东西，即使维护成本很高，也要继续进行风险重写。特别是如果该功能对业务至关重要。
您有机会添加主要功能，并且可以将其作为不改为重写的风险。
但是，您可能只需要在显示所拥有的内容之前进入“工作原型”实现。提供迁移计划和兼容性测试计划。
如果重写在明年总计需要6个月，那么请确保节省的成本高于保留现有系统的成本。很多人不会在意这些节省是否仅在三年或更长时间内实现。
我们是重写系统，但它们是具有重要年度许可成本的系统，这些系统对业务至关重要。一个六个月的重写和2个月/月的维护是一个简单的销售，更别提其他好处，例如大大提高系统的准确性（导致需要指导旧系统的人员的冗余）。总而言之，这些节省使得公司在最近的经济衰退期间更加活跃，并将为我们带来竞争优势。