处理重构大文件的最佳方法是什么？

我目前正在做一个更大的项目，不幸的是其中有些文件的软件质量准则并不总是遵循的。这包括大文件（读取2000-4000行），这些文件显然包含多个不同的功能。

现在，我想将这些大文件重构为多个小文件。问题是，由于它们很大，因此不同分支上的多个人（包括我）正在处理这些文件。因此，我无法真正从开发和重构中分支出来，因为将这些重构与其他人的更改合并将变得很困难。

当然，我们可以要求每个人重新合并以开发，“冻结”文件（即，不再允许任何人对其进行编辑），重构然后“取消冻结”。但这也不是一件好事，因为这将要求每个人在重构完成之前基本上停止对这些文件的工作。

因此，有没有一种方法可以重构，不要求其他人停止工作（很长时间）或合并其功能分支以进行开发？

您已经正确地理解，这不仅仅是技术问题，而是社会问题：如果要避免过多的合并冲突，团队需要以避免这些冲突的方式进行协作。

这是Git更大问题的一部分，因为分支非常容易，但是合并仍然需要很多努力。开发团队倾向于创建很多分支，然后感到惊讶的是，合并它们很困难，可能是因为他们在不了解其上下文的情况下试图模仿Git Flow。

快速轻松合并的一般规则是防止累积大差异，尤其是要素分支的生存期应非常短（数小时或数天，而不是数月）。能够快速集成其更改的开发团队将看到较少的合并冲突。如果某些代码尚未投入生产，则可以将其集成，但可以通过功能标记将其停用。一旦将代码集成到您的master分支中，您便可以尝试进行重构。

对于您眼前的问题，这可能太多了。但是可能可行的是，要求同事合并影响该文件的更改，直到一周结束，以便您可以执行重构。如果他们等待更长的时间，他们将不得不自己处理合并冲突。这不是不可能的，只是可以避免的工作。

您可能还想防止破坏大量的相关代码，而仅进行与API兼容的更改。例如，如果要将某些功能提取到单独的模块中：

1. 将功能提取到单独的模块中。
2. 更改旧函数以将其调用转发到新API。
3. 随着时间的流逝，将依赖于代码的代码移植到新的API。
4. 最后，您可以删除旧功能。
5. （重复下一组功能）

此多步骤过程可以避免许多合并冲突。特别是，只有当其他人也在更改您提取的功能时，才会出现冲突。这种方法的成本是，它比一次更改所有内容要慢得多，并且您暂时拥有两个重复的API。直到紧急情况中断此重构，重复被遗忘或取消优先级，并且最终导致一大笔技术债务之后，情况才算好。

但是最后，任何解决方案都需要您与团队协调。

以较小的步骤进行重构。假设您的大文件名为Foo：

1. 添加一个新的空文件，Bar并将其提交到“ trunk”。

2. 找到一小部分Foo可以移至的代码Bar。应用移动，从主干更新，构建和测试代码，然后提交到“ trunk”。

3. 重复第2步，直到Foo并Bar具有相等的大小（或您喜欢的任何大小）

这样，下次您的队友从主干更新分支时，他们会在“小部分”中获得更改，并且可以将它们逐一合并，这比必须一步合并一个完整的分支要容易得多。当在第2步中发生合并冲突时，情况也是如此，因为其他人在两者之间更新了中继。

这不会消除合并冲突或需要手动解决它们，但是会将每个冲突限制在较小的代码区域中，这更易于管理。

当然-在团队中沟通重构。通知您的伴侣您在做什么，这样他们就知道为什么他们必须期望特定文件的合并冲突。

您正在考虑将文件拆分为原子操作，但是可以进行一些中间更改。文件随着时间逐渐变大，可能随着时间而逐渐变小。

选择一个不需要很长时间进行更改的零件（git blame可以帮助您完成此工作），然后首先将其拆开。将更改合并到每个人的分支中，然后选择下一个最容易拆分的部分。甚至分割一个部分都太大了，您应该首先在大文件中进行一些重新排列。

如果人们不经常合并以进行开发，则应鼓励他们，然后在合并后利用这个机会将刚更改的部分分开。或要求他们进行拆分，作为拉取请求审核的一部分。

这个想法是要慢慢地朝自己的目标迈进。感觉进度很慢，但是突然之间，您就会意识到自己的代码要好得多。转动远洋客轮需要很长时间。

我将针对此问题提出一种不同于通常的解决方案。

将此用作团队代码事件。让每个人都可以签入自己的代码，然后帮助仍在使用该文件的其他人。一旦每个相关人员都将其代码签入，请找到一台配有投影仪的会议室，并一起工作以开始将内容四处移动并移动到新文件中。

您可能需要为此设置一个特定的时间，这样就不会浪费一个星期的时间而没有结束的争论。取而代之的是，这甚至可能是每周一次的1-2小时活动，直到大家都了解它的状态。也许您只需要1-2个小时即可重构文件。您可能直到尝试才知道。

这样做的好处是每个人都可以在同一页面上进行重构，而无需双关语，但是它也可以帮助您避免错误，并在必要时从其他人​​那里获取有关可能的方法分组的输入。

如果您这样做的话，可以认为这样做具有内置的代码审查功能。这样一来，有相应数量的开发人员就可以在签入代码后立即签收代码，并准备对其进行审核。您可能仍然希望他们检查代码中是否缺少任何内容，但是要确保缩短审核过程有很长的路要走。

这可能不适用于所有情况，团队或公司，因为工作分配的方式并不容易做到。也可以（错误地）将其解释为滥用开发时间。该组代码需要管理者的支持以及重构本身。

为了帮助您将此想法卖给您的经理，请提及代码审查位，以及每个人从一开始就知道事情在哪里。避免开发人员浪费时间搜索大量新文件是值得避免的。同样，防止开发人员获得关于事情在哪里结束或“完全丢失”的信息通常是一件好事。（IMO崩溃越少越好。）

一旦以这种方式重构了一个文件，如果成功且有用的话，您便可以更轻松地获得批准以进行更多重构。

但是，您决定进行重构，祝您好运！

要解决此问题，需要其他团队的支持，因为您正在尝试更改共享资源（代码本身）。话虽如此，我认为有一种方法可以“迁移”拥有庞大的整体文件而不会打扰人们。

我还建议不要一次将所有大文件作为目标，除非除了单个文件的大小之外，大文件的数量不受控制地增长。

像这样重构大文件经常会导致意外问题。第一步是阻止大文件积累除master或development分支中当前可用的功能以外的其他功能。

我认为最好的方法是使用提交钩子，这些钩子默认情况下会阻止对大文件的某些添加，但是可以用提交消息中的神奇注释（如之类的@bigfileok东西）来否决。能够以无痛但可跟踪的方式推翻该政策非常重要。理想情况下，您应该能够在本地运行提交挂钩，并且应该告诉您如何在错误消息本身中覆盖此特定错误。另外，这只是我的偏爱，但是无法识别的魔术注释或魔术注释抑制了在提交消息中并未真正触发的错误，这应该是一个提交时间警告或错误，因此您不会无意中培训人们抑制钩子，无论他们是否需要。

提交钩子可以检查新类或进行其他静态分析（临时或不临时）。您还可以选择比当前文件大10％的行或字符数，并说大文件不能超过新的限制。您也可以拒绝使大文件增加太多行或太多字符或w / e的单个提交。

大文件停止累积新功能后，您可以一次将其重构（并同时减少提交钩子强制执行的限制，以防止其再次增长）。

最终，大文件将足够小，可以完全删除提交挂钩。

等到回家。拆分文件，提交并合并到母版。

像其他任何更改一样，其他人必须在早上将更改拉入其功能分支。