您是否应该重构专注于新功能的项目中未破坏的现有代码？

给定一个旨在为应用程序添加新功能的小型项目，所引入的更改涉及一些现有代码，涉及在某些领域中进行更新。在实施期间，我发现其中一些更新的代码具有重构的候选对象。

这是否是一个适当的重构时间，从而又需要对受影响的那些组件进行回归测试（因此可能引入的范围最初不是项目的一部分）？还是我应该推迟，完成功能，也许有一个单独的项目进行重构（尽管我有点犹豫，因为业务用户可能不会完全赞助一个不添加任何功能的项目，除非他们重视代码的可维护性...）？

绝对。

重构应该在一个正在运行且“通过”的项目上进行。当所有测试（在单元，系统和验收级别）通过时，您就知道您的产品符合要求。重构时，您可以继续确认所有测试继续通过。如果任何测试开始失败，则说明您做错了什么，需要更正。如果测试失败，则应在重构之前更正这些错误，以便始终确保重构不会改变系统的功能。

假设您有足够的时间和资源进行重构，并且仍然按时交付预算，这也是重构的理想时机。现在进行重构将使您更容易理解和维护您的系统，因此，当您添加更多新功能时，它将变得更加容易。您需要与代码腐烂和软件熵作斗争。

正如Joel Etherton在评论中指出的那样，您需要管理重构的范围。着重于重构即将向其添加功能的系统部分，执行重构以使其更易于使用或添加新功能。使用静态分析，指标工具和代码审查可以帮助您确定最关键的领域。您不想因为重组而错过最后期限-您仍然需要继续为客户增加价值。

您提到客户在重构中看不到价值。通常，客户不在乎代码的质量，而在乎产品的质量。重构将使您更轻松地保持高质量的产品，并不断交付满足客户不断变化的需求的产品。尝试协商时间以将其重构到计划中（客户希望在Y天获得X个功能，请尝试查看是否无法获得Y + Z天或XN个功能，以便可以将时间花在设计，重构和实现上）能够。

考虑回答以下问题，那么您可以轻松做出决定。“如果没有损坏就不要修复”的想法很诱人，但对于专业工作并不总是如此。

0-客户对此代码有投诉吗？

1-这对于应用程序的功能是否必要

2-当前代码有害吗？

3-改变的成本值得吗？

4-您负担得起费用吗？

5-这是对组织的最佳技能利用吗

6-您的更改是否需要您的用户重新安装新的更改-您能否向客户证明这一点？

7-您能忍受错误修复的风险吗？

8-更改是否会影响项目外的其他代码？

9-这是不断发展的产品还是稳定的产品？如果正在发展，您可以在下一个版本中包含更改吗？

重构很快，经常重构。

如果您负担得起（时间，金钱等），则应该这样做。

我之所以这样说，是因为有时您可能会用完时间，或者说您没钱进行代码维护干预，或者您想尽快完成您的项目，并且通常来说，这是因为重构需要资源。但是除此之外，它始终是重构的好时机。

您需要一个最新的代码，并且如果您觉得您的代码实际上需要进行一些更改，尤其是在添加新功能时，则应该对其进行更改。

别忘了使用版本控制系统，您实际上可以将项目分叉到新的分支中，因此完全不会影响当前的代码。

如果需要重构来实现新功能，则应将其完成并纳入新开发的一部分。

从长远来看，重复的代码会使您（包括您个人和公司）花费更多，因为对一个地方而不是另一个地方进行编辑。

您确实需要一组测试-可以运行的自动化单元测试或回归测试，以证明您没有对现有功能引入问题。

如果重构只是一件“好事”，即重构中的代码不受新功能的直接影响，那么我将不理会它。您是为了更改而引入更改。

听起来好像重构代码将使添加新功能更加容易。这就是理论。将此包含在新功能的范围内。通过这种方式，您更有可能获得业务用户的支持。在这种情况下，您应该能够做出令人信服的论据并为重构时间辩护。希望他们能理解这是开发过程中必不可少的部分，并且会减少异议。您可能并不总是能够证明这种直接的好处。