如何证明代码重构时间？

有一个超过70k LOC的大型项目。

该项目肯定需要在Core Framework和其他部分中进行一些代码重构。在项目开始时没有设置任何时间进行重构。但是随着时间的推移，有40多个开发人员加入并离开了该项目。在我看来是必不可少的。

在争论和捍卫适当的软件开发原则时，您的重点是什么？

当在遗留或棕地应用程序上工作时，很容易进行“春季大扫除”，以期将整个组件重构为整形。这绝不是合理使用资源的方式。毕竟，如何合理地停止开发工作软件（只能重构工作代码）？您能保证花在大重构阶段上的时间会在以后得到回报，并且不会导致项目退化吗？

你怎么吃大象？一次咬一口。每当您需要实施新功能或修复错误时，您都会查看该部分是否需要改进。就像童子军规则说的那样：“永远离开营地，要比发现的要干净。” 重构不应该是一个单独的阶段，它是日常开发的一部分。

当您将这种质量文化引入开发团队时，质量将会提高。此后，没有任何理由可以向管理层证明。

通常，应该进行重构以启用您需要对代码进行的另一更改，或者作为对代码进行更改后的自然清除步骤。在这种情况下，没有任何理由可以证明。重构只是在项目上进行工作的一部分。时间是根据您进行重构时正在处理的任务计费的。

如果不是以很小的增量完成，那么它就不是真正的重构，是吗？

这里所有的好答案-但我可以在此添加业务范围。让我问问你为什么/为什么？（想想你尖尖的头发老板（PHB）：）

PHB：为什么？
您：它将使事情更容易修复
PHB：怎么样？
您：它将提高吞吐量-我们将更快地推出新产品吗？
PHB：怎么样？
您：呃...更快乐的客户？
PHB：WTF？
您：我的意思是增加建议，提高满意度， 
     由于周转率低，因此可以更快获得更多利润
PHB：哦！听起来不错。但是，只有“声音”好看吗？
您：WTF？
PHB：告诉我钱！（请输入数字）
你：哦！Brb ...（在简单的电子表格中输入一些数字即可得出结论）

基本上，您必须提出一个业务案例-运行一些数字以阐明您的思考过程，并获取数字以客观地反映“收益”。您还将知道将花费多少时间，大概的费用等。这应该是有道理的。如果这是值得的，那么您将获得绿色信号，并可能也率先采取主动行动:)

如果您认为我该如何衡量所有内容，请尝试这本书

像其他任何活动一样，重构必须为其定义明确的目标。明确目标之后，您将考虑当前项目状态和生命周期阶段。对于已完成80％，比计划晚30％的开发项目，您应该根据先前设定的目标证明重构工作的合理性。在此示例中，如果代码段经过单元测试并且在开发环境中运行良好，则很难证明重构是合理的。

剩下40名开发人员的事实可能并不像听起来那样具有戏剧性。我希望那些开发人员提供了经过审查和测试的工作代码。因此，除非这段代码中存在已知问题，否则我将保持原样。我的想法是，在像您这样的大型项目中，我希望有标准和程序，并且代码不是一团糟。

请记住，重构将导致许多（如果不是全部）测试被重复。而且，由于无法由一个或两个高级成员来完成此大小的重构，因此重构可能会引入不存在的问题。这是不容忽视的风险。

话虽如此，当发生不可预见的情况时，将任务添加到项目中并不罕见。因此，如果开发者因某种原因而失踪，那将被视为具有特殊性质的事件，并且必须采取任何补救措施来纠正这种情况。它将被视为火灾或地震等。

总而言之，我不会在没有充分可靠的技术理由的情况下重构大型项目中的大型工作代码，特别是我们都知道大多数项目通常处于后期状态。

想象一下，您正站在一堵长而巨大的墙前。您需要去另一边。

您可以重构墙以建造一扇门，也可以绕一圈。

估计两种解决方案的时间，您就会得到重构的理由。

不要忘记将第二种解决方案中的时间乘以需要到达隔离墙另一侧的人数。

正如我在其他答案中读到的那样，一次吃一口大象。我参与审核一个大型国际项目，该项目的团队成员分散在各个地方。在构建了软件的前两个版本之后，团队同意他们的方法，编码风格和构建解决方案不一致。他们同意遵循新的规则和约定编写应用程序的新部分，并且（只有那时）他们不得不更改一些旧代码时，他们首先将其重构以符合新的约定。一切工作都很好。重构过程几乎在第5个月，一些代码已经重构，有些还没有。新功能及时出现，客户满意，开发人员满意，QA团队也满意。双赢局面:)

重构的主要目的是使将来的事情变得更容易。您不能显示重构的利润，除非您比较多个长期项目，很少执行和不进行长期重构。重构可以降低维护和实施变更的成本，这在开发人员中是普遍接受的，但是从业务的角度来看，这些很难证明。实施重构的关键原因在于减少技术债务。

而且，重构应该是连续的过程，并且在重构上花费的时间应该包括在开发任务本身中。具有特殊的“重构任务”不是一个好主意。