我完全赞同 TDD、重构和模式背后的想法，但是这些想法似乎确实存在巨大的差距，主要是它们非常适合 1 人的开发团队，但是当你开始重构代码时，10 人是处理您的工作时，您开始在各处遇到合并冲突，并且大多数 diff/merge 软件无法判断您将函数重构为自己的类。
你如何通过重构来清理你的代码，而不会给团队中的每个人带来严重的麻烦？
Jim
问问题
759 次
9 回答
6
经常提交的小改动。
至于您的示例，您将从创建类开始，提交该更改。然后在类中添加一个与旧函数类似的函数并提交该更改。然后将所有引用从旧函数更改为新的类函数，提交。然后删除旧函数并提交该更改。
当然，没有人说这会很容易。
于 2008-09-16T01:17:57.527 回答
2
经常签到。团队成员应该每天至少检查一次他们的更改并重新同步他们的沙箱。随着更频繁的签入，合并冲突将更少发生，并且在发生时更易于管理。
于 2008-09-16T01:20:36.020 回答
1
当我认为重构将难以合并时，我会这样做：
- 警告我的团队即将发生更改，并检查是否有任何难以合并的待处理更改。
- 确保我了解我将要做出的改变，这样我才能快速做出改变。如果需要，现在增强测试覆盖率。
- 将我的机器同步到最新的源。
- 重构、测试和提交。
- 通知我的团队，以便他们可以同步我的更改。
请注意，我将重构更改与功能更改分开进行。
于 2008-09-27T03:48:03.637 回答
1
好吧，在实践中，这很少成为问题。通常不同的团队成员在代码的不同区域工作，所以没有冲突。此外，大部分重构将在您进行 TDD 时进行（甚至可能在您签入代码之前，但最肯定的是在其他人开始使用和修改它之前）。
如果您发现由于重构而产生了很多冲突，请尝试更频繁地签入，或者让人们知道谁可能正在处理您即将进行一些重大返工的相同代码。沟通总是有帮助的。
于 2008-09-16T01:16:37.293 回答
1
我认为你的团队必须支持你的改变。如果您正在进行大型重构，对代码库和对象层次结构进行重大更改，您将希望作为一个团队讨论这些更改。
于 2008-09-16T01:27:39.983 回答
0
根据我的经验，在对敏捷项目进行中小型重构时，合并冲突很少成为问题。大量的重构工作可能会引入一些合并的痛苦，但如果它以一口大小的块完成，则可以显着减少痛苦。使用 Subversion 作为 SCM 也可以减少合并的痛苦，因为 SVN 会自动合并非冲突的更改。
这种策略对于我参与过的团队来说效果很好，而且这些团队中的大多数都是 4 个以上的开发人员对。
于 2008-09-16T01:30:10.443 回答
0
你必须从小而慢开始。取一部分代码并查看所有外部接口。你必须绝对确保这些不会改变。现在您已经定义了它，开始查看它的内部结构并慢慢改变它。您必须分小步进行工作并经常签入以避免大规模的合并冲突，这是您必须解决的最大问题之一。在这样规模的团队中，您永远无法检查所有内容并神奇地让他们变得更好。您可能想让人们提前知道您将要做什么。（无论如何，您应该始终计划好您要做什么）。如果其他人正在研究它，让他们知道会发生什么变化以及它将如何影响课堂等。
在你开始尝试之前，你要知道的最重要的事情是人们是否和你在一起。如果没有，它可能是一个失败的原因，并会引起冲突。在这种情况下，糟糕的代码和一个能够以这种方式理解混乱的运作团队可能比重构的代码更好。知道这是违反直觉的，但是我以前工作的老板是这样说的。他说代码很糟糕，但它可以工作，这里的开发人员知道它是如何工作的，这意味着使用它的 1000 人可以完成他们的工作，这意味着我们可以保留我们的工作。我们讨厌代码并想更改它，但他是对的。
于 2008-09-16T01:25:18.443 回答
-1
沟通。
工具无法为您解决这个问题，除非特定工具是您的电子邮件或 IM 客户端。
就像您在共享项目中进行任何其他重大更改一样 - 您需要能够告诉您的同事/合作者“嘿，放手几个小时，我对 FooBar 模块进行了重大更改在”。
或者，如果您要进行重大更改以致可能与其他 10 人的工作造成巨大的合并冲突，请事先由他们进行更改。进行代码审查。请求架构输入。然后，当您尽可能接近达成共识时，将虚拟锁锁定在您需要的存储库部分，签入您的更改，然后发出一个完全清除的消息。
这不是一个完美的解决方案，但它尽可能接近。许多源代码控制系统支持对源代码库的各个部分进行显式锁定，但我从未真正看到那些在这些领域产生好的结果。这是一个社会问题，如果你不能信任与你一起工作的人，你才真正需要求助于技术解决方案。
于 2008-09-16T01:20:03.260 回答