我完全支持TDD，Refactoring和Patterns背后的想法，但是这些想法似乎有很大的差距，主要是它们对于1个开发团队来说非常有用，但是当我们开始重构代码时，有10个人在进行工作时，到处开始出现合并冲突，大多数差异/合并软件无法告诉我们将函数重构为自己的类。

我们如何通过重构来清理代码，而又不会引起团队中每个人的头疼呢？

解决方案

回答

好吧，实际上，这很少是一个问题。通常，不同的团队成员在代码的不同领域工作，因此不会发生冲突。而且，大部分重构将在执行TDD时进行(甚至可能在签入代码之前，但最肯定是在其他人开始使用和修改它之前)。

如果发现由于重构而造成很多冲突，请尝试更频繁地检入，或者让其他人知道可能正在使用我们将要进行一些重大返工的相同代码。交流总是有帮助的。

回答

经常进行小的更改。

对于示例，我们将从创建类开始，然后提交该更改。然后在类中添加一个与旧函数相似的函数，然后提交该更改。然后将所有引用从旧函数更改为新类函数，然后提交。然后删除旧功能并提交更改。

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

回答

沟通。

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

就像我们在共享项目中进行其他任何重大更改一样，我们需要告诉同事/协作者"嘿，放开几个小时，我对即将发布的FooBar模块进行了重大更改"。

或者，如果我们要进行的更改如此重要，以至于可能与其他10个人的工作产生巨大的合并冲突，请事先由他们进行更改。进行代码审查。要求建筑意见。然后，当我们尽可能接近达成共识时，在所需存储库部分上使用该虚拟锁，签入更改，然后发出清晰的通知。

这不是一个完美的解决方案，但将尽我们所能。许多源代码控制系统都支持对源代码库的某些部分进行显式锁定，但我从未真正看到过这些方法在这些方面会产生良好的效果。这是一个社会问题，如果我们不信任与之共事的人，则只需要求助于技术解决方案。

回答

经常签到。团队成员应该每天检查一次更改并重新同步其沙盒。随着签入次数的增加，合并冲突的发生频率会降低，并且在发生冲突时更易于管理。

回答

我们必须从小处开始。阅读一部分代码，并查看所有外部接口。我们必须绝对确保这些内容不会改变。现在，我们已经定义了它，开始研究它的内部结构并慢慢地对其进行更改。我们必须分步骤进行，并经常检查，以免发生大规模合并冲突，这是我们将要解决的最大问题之一。在这样规模的团队中，我们将永远无法检查所有内容，并以神奇的方式使它们变得更好。我们可能想让人们提前知道我们将要做什么。 (无论如何，我们都应该先计划一下要做什么)。如果其他人正在研究它，请让他们知道将会发生什么变化以及它将如何影响班级等。

在开始尝试之前，我们要了解的最大问题是，如果有人在陪伴我们。如果不是，那可能是一个失败的原因，并会引起冲突。在这种情况下，糟糕的代码和能以混乱的方式了解混乱的运作团队可能比重构代码更好。知道这是反直觉的，但是我以前的工作中的老板是这样说的。他说代码很可怕，但是可以工作，这里的开发人员知道它是如何工作的，这意味着使用它的1000人可以完成工作，这意味着我们必须保留自己的代码。我们讨厌该代码，并希望对其进行更改，但他是对的。

回答

我认为团队必须顺应变化。如果我们要进行大型重构，并对代码库和对象层次结构进行较大更改，那么我们将需要团队讨论更改。

回答

以我的经验，在敏捷项目中进行中小型重构时，合并冲突很少成为问题。大量的重构工作可能会带来一些合并痛苦，但是如果以小块块的形式进行合并，则可以显着减少痛苦。也可以通过使用Subversion作为SCM来减轻合并痛苦，因为SVN会自动合并无冲突的更改。

这个策略对我所参与的团队非常有效，其中大多数团队都是4对以上的开发人员。

回答

我认为我们应该提出一些问题，以了解重构为何会损害源代码控制。

• 为什么有10个人同时更改同一代码？
• 有更好的工具可以进行重构/合并(也许是分布式版本控制)？

对于第一个问题，也许我们没有很好地分离关注点，并且代码紧密耦合。也许团队在分配任务时沟通不畅。对于第二个问题，好吧，尝试一些好的dvc(git，mercurial，bazaar)，看看是否有什么可以帮助。

亲切的问候

回答

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

• 警告我的团队更改即将到来，并检查是否有任何待合并的更改将很难合并。
• 确保我了解我将要进行的更改，因此我可以快速进行更改。如果需要，现在增强测试范围。
• 将我的机器同步到最新的源。
• 重构，测试和提交。
• 通知我的团队，以便他们可以同步我的更改。

请注意，我将与功能更改分开进行重构更改。