重构和源代码控制：如何？

Question

我完全接受了TDD，Refactoring和Patterns背后的想法，但是看起来这些想法似乎存在巨大的差距，主要是它们对于1的开发团队来说非常棒，但是当你开始重构代码时10个人正在努力让你开始在整个地方发生合并冲突，大多数差异/合并软件都无法告诉你将函数重构到自己的类中。

如何通过重构来清理代码，而不会给团队中的每个人带来严重的麻烦？

Answer 1

经常发生微小变化。

至于你的例子，你将从创建类开始，提交更改。然后在类中添加类似的旧函数并提交更改。然后将旧函数的所有引用更改为新的类函数，提交它。然后删除旧函数并提交更改。

当然，没有人说这会很容易。

Answer 2

经常检查。团队成员应该检查他们的更改并每天重新同步他们的沙箱至少一次。通过更频繁的检查，合并冲突将更少发生，并且在发生时更容易管理。

Answer 3

我认为您应该问一些问题，以了解为什么重构会损害源代码控制。

• 为什么10个人同时更改相同的代码？
• 有更好的工具可以帮助您进行重构/合并（可能是distributed version control）？

对于第一个问题，也许你没有很好的分离关注，代码紧密耦合。或者在分配任务时，团队可能没有很好地沟通。对于第二个问题，请尝试一些好的dvcs（git，mercurial，bazaar）并查看是否有任何可以帮助您。

亲切的问候

Answer 4

嗯，实际上这很少是一个问题。通常不同的团队成员正在处理代码的不同区域，因此没有冲突。此外，大部分重构将在您执行TDD时进入（甚至可能在您检查代码之前，但绝大多数在其他人开始使用和修改之前）。

如果您发现由于重构而导致冲突很多，请尝试更频繁地检查，或让人们知道谁可能正在使用相同的代码，您将要做一些重大的返工。沟通总是有帮助的。

Answer 5

我认为您的团队必须参与您的更改。如果您正在进行大型重构，对代码库和对象层次结构进行重大更改，那么您将希望以团队形式讨论这些更改。

Answer 6

当我认为重构很难合并时，我会这样做：

1. 警告我的团队即将进行更改，并检查是否有任何难以合并的待更改。
2. 确保我理解我要做的改变，所以我可以快速完成。如果需要，现在增强测试覆盖率。
3. 将我的机器同步到最新来源。
4. 重构，测试和提交。
5. 通知我的团队，以便他们可以同步我的更改。

请注意，我的重构更改与功能更改分开。

Answer 7

你必须慢慢开始。获取一部分代码并查看所有外部接口。你必须绝对确保这些不会改变。现在您已经定义了开始查看它的内部结构并慢慢改变它。你必须小步工作并频繁登记，以避免大规模的合并冲突，这是你必须要解决的最大问题之一。在一个规模很大的团队中，你永远无法检查所有东西，并且神奇地让它们变得更好。您可能希望提前让人们知道您要做什么。 （无论如何，你应该总是计划你做的事情）。如果其他人正在研究它，请告诉他们将要改变的内容以及它将如何影响课程等。

在你开始尝试之前，你要发现的最重要的事情就是人们和你在一起。如果没有，它可能是一个失败的原因，并将导致冲突。在这种情况下，糟糕的代码和一个能够理解混乱的功能团队可能比重构代码更好。知道这是违反直觉的，但是我老工作的老板就是这样说的。他说代码太可怕了，但它确实有效，而且这里的开发人员知道它是如何工作的，这意味着使用它的1000人可以完成他们的工作，这意味着我们可以保留我们的工作。我们讨厌代码，想要改变它，但他是对的。

Answer 8

根据我的经验，在对敏捷项目进行中小规模重构时，合并冲突很少成为问题。大的重构努力可能会引入一些合并疼痛，但如果它在一口大小的块中完成，疼痛可以显着减少。使用Subversion作为您的SCM也可以减少合并痛苦，因为SVN将自动合并非冲突的更改。

这个策略对我参与的团队运作良好，而且大多数团队都是4+开发人员。

Answer 9

通信。

除非特定工具是您的电子邮件或IM客户端，否则工具无法为您解决此问题。

就像你在共享项目中进行任何其他重大改变一样 - 你需要能够告诉你的同事/合作者“嘿，放手几个小时，我有一个很大的改变FooBar模块进入“。

或者，如果您要进行如此重大的更改，以至于它可能会导致与其他10个人的工作发生巨大的合并冲突，请事先对其进行更改。进行代码审查。要求建筑输入。然后，当您尽可能接近达成共识时，在您需要的存储库部分上获取该虚拟锁定，检查您的更改，并发送全部清除。

这不是一个完美的解决方案，但它会尽可能接近你。许多源代码控制系统支持源代码部分的显式锁定，但我从未真正看到这些在这些领域取得了良好的效果。这是一个社会问题，如果你不相信与你合作的人，你真的需要求助于技术解决方案。