相反它们提供了做出决定时

需要考虑的必要信息。因此，它们有助于描绘出重写可能意味着什么的更现实的画面。 设计关键方法 由于大多数软件工程师在需要改进现有系统时都会考虑重写，因此必须从重写开始。考虑业务驱动因素和相关风险可能是决定重写是否适合您的好方法。简而言之，在考虑整个事情的技术方面之前，您需要定义重写对您来说是否是一个可行的选择。 不过，这样做有一件棘手的事情。您可能正在考虑重写或重构，因为您有太多的技术债务，或者您的软件接近过时。在这种情况下，这两种选择都有风险。如果仅仅因为一切正常而保持不变，那么您的软件将面临无法长期支持、在不久的将来无法维护或无法扩展的风险。如果重写它，您可能无法获得相同的功能。 这意味着不存在无风险的选择——考虑你的选择并意识到它们，但不要仅根据风险（或不存在风险）做出决定，仅仅因为没有任何情况可以让你摆脱风险。


 因此，我认为最好的看待它的方式如下： 考虑任一选项的业务影响。它们的潜在后果是什么？ 分析和评估风险。其中一种选择可能比另一种风险更大，但也不一定。你明白走一条路或走另一条路意味着什么吗？ 概述您想要重构或重写的原因。你想达到什么目的？ 确定您当 电话号码清单 前的软件距离这些目标有多远。尽可能详细。 定义一条清晰的路径，将您从现在的位置带到您想要的位置。有可能吗？也许与新技术不兼容，或者没有任何途径将过时的软件改造成现代硬件。 沿着该路径分解两个流程。重构代码涉及哪些内容？重写中包含哪些内容？这是评估的关键部分，因此不要试图用您认为这两个过程将花费多少时间来表达该过程。





相反，尝试考虑任务及其复杂性，因为这样可以更好地比较这两个选项。 比较你面前的路径。也许您会发现，虽然重构可能需要更多步骤，但这些步骤比重写中包含的更少步骤更容易。或者也许很明显，重构是一项难以克服的努力，因为它意味着许多任务。 更清晰地了解这两条路径后，重新评估您的业务驱动因素和风险。考虑到所有这些因素后，您将更好地准备做出最终决定。 当涉及到日常操作时，重构与重写的争论是一场毫无结果的争论，因为它经常偏离理论领域。由于没有两个项目是相同的，因此必须仔细检查这些实际步骤，以便更好地处理该主题并确定一条道路是否更好。 我的最后一个建议。即使您发现某种方法为您的项目带来了更好的结果，也要抵制将该选项作为默认选项的诱惑，因为您可能会遇到可能从其他方法中受益的特定项目。每次使用旧代码时都进行这种分析似乎很烦人，但我向您保证这是您的项目获得最佳结果的唯一方法。