我的团队如何在重构后避免频繁的错误？

为您提供一些背景知识：我在一家大约有十二名Ruby on Rails开发人员（+/-实习生）的公司工作。远程工作很普遍。我们的产品由两部分组成：一个相当肥大的核心，然后精简到以此为基础的大客户项目。客户项目通常会扩展核心。不会覆盖关键功能。我可能还会补充说，核心中有一些非常糟糕的部分，这些部分迫切需要重构。有规格，但主要针对客户项目。核心的最差部分未经测试（不是应该的……）。

开发人员分为两个团队，每个sprint使用一个或两个PO。通常，一个客户项目严格与团队和PO之一相关联。

现在我们的问题是：我们经常破坏彼此的东西。A团队的某人扩展或重构了核心功能Y，从而为B团队的一个客户项目造成了意外错误。通常，更改不会在团队中宣布，因此这些错误几乎总是无法预料的。包括PO在内的B团队认为功能Y是稳定的，并且在发布之前未对其进行测试，并且没有意识到更改。

如何摆脱那些问题？您可以推荐我什么样的“公告技术”？

我建议阅读Michael C. Feathers撰写的《有效使用旧版代码》。它说明您确实需要自动测试，如何轻松添加它们，如果还没有自动测试，以及哪种“代码味道”以何种方式重构。

除此之外，您遇到的另一个核心问题似乎是两个团队之间缺乏沟通。这些团队有多大？他们在处理不同的积压工作吗？

根据您的体系结构拆分团队几乎总是​​一种不好的做法。例如核心团队和非核心团队。相反，我将在功能域（但跨组件）上创建团队。

我们最核心的部分未经测试（应该如此）。

这就是问题。高效的重构在很大程度上取决于自动化测试套件。如果没有这些，您所描述的问题就会开始出现。如果您使用像Ruby这样的动态语言，这尤其重要，因为该语言没有编译器来捕获与将参数传递给方法有关的基本错误。

先前的指向您指出更好的单元测试的答案是好的，但是我认为可能还有更多基本问题需要解决。您需要清晰的界面来访问客户项目代码中的核心代码。这样，如果您重构核心代码而不改变通过接口观察到的行为，那么其他团队的代码将不会中断。这将使您更容易知道可以“安全”重构的内容以及需要重新设计（可能是接口中断）的内容。

其他答案也强调了重点（更多的单元测试，功能团队，与核心组件的简洁接口），但是我发现有一点缺失，那就是版本控制。

如果您通过执行发行版^1来冻结核心的行为，并将该发行版放入私有工件管理系统^2中，则任何客户项目都可以声明其对核心版本X的依赖关系，并且下一发行版X不会破坏该依赖项。+1。

然后，“公告政策”只是简化为在每个发行版中都包含一个CHANGES文件，或者召开团队会议来宣布每个新核心发行版的所有功能。

另外，我认为您需要更好地定义什么是“核心”，以及哪些是“关键”。您似乎（正确地）避免对“关键组件”进行许多更改，但允许对“核心”进行频繁更改。为了依靠某些东西，您必须保持它稳定。如果某些东西不稳定，请不要将其称为核心。也许我建议将其称为“帮助”组件？

编辑：如果您遵循语义版本控制系统中的约定，则内核API中任何不兼容的更改都必须由主要版本更改来标记。也就是说，当您更改以前存在的内核的行为或删除某些内容时，不仅要添加新内容。按照这种约定，开发人员知道从版本'1.1'升级到'1.2'是安全的，但是从'1.X'升级到'2.0'是冒险的，必须仔细检查。

^{1：在Ruby的世界中，我认为这被称为宝石
2：等效于Java中的Nexus或Python中的PyPI}

就像其他人所说的那样，一套好的单元测试套件并不能解决您的问题：即使每个团队测试套件通过了，您在合并变更时也会遇到问题。

与TDD相同。我不知道它如何解决这个问题。

您的解决方案不是技术性的。您需要明确定义“核心”边界，并为某人（无论是首席开发人员还是架构师）分配“看门狗”角色。对内核的任何更改都必须通过此看门狗。他负责确保所有团队的每个输出都可以合并，而不会造成过多的附带损害。

作为更长期的解决方案，您还需要团队之间更好，更及时的沟通。每个将利用例如核心功能Y的团队都需要参与构建该功能的计划测试用例。该计划本身将突出显示两个团队在功能Y中固有的不同用例。一旦确定了功能的工作方式，并且测试用例已实现并达成共识，就需要对实现方案进行其他更改。发布该功能的团队需要运行测试用例，而不是将要使用它的团队。可能引起碰撞的任务是从两个团队中的一个添加新的测试用例。当团队成员想到未经测试的功能的新方面时，他们应该可以自由地添加已验证通过自己沙盒的测试用例。这样，将发生的唯一碰撞将是在意图级别上，并且应该在将重构功能发布到野外之前将其确定下来。

尽管每个系统都需要有效的测试套件（除其他外，这意味着自动化），并且这些测试（如果得到有效使用）将比现在更快地抓住这些冲突，但这并不能解决潜在的问题。

该问题至少揭示了两个基本问题：修改“核心”以满足个人客户需求的实践，以及团队无法沟通和协调他们进行变更的意图。这些都不是根本原因，因此您需要先了解为什么这样做，然后再进行修复。

首先要确定的事情之一是开发人员和管理人员是否都意识到这里存在问题。如果至少有人这样做，那么您需要找出为什么他们要么认为自己对此无能为力，要么选择不这样做。对于那些没有这样做的人，您可以尝试提高他们的能力，以预测他们当前的行为可能会如何造成未来的问题，或者由有能力的人来代替。除非您的员工知道问题的根源，否则您不太可能解决问题（至少在短期内，甚至不可能）。

至少从一开始就很难用抽象的术语来分析问题，因此请专注于导致问题的特定事件，并尝试确定问题的发生方式。由于涉案人员可能会采取防御措施，因此您需要警惕自我服务和事后证明，以查明实际情况。

我不愿提及一种可能性，因为它不太可能发生：客户的需求是如此分散，以至于通用性不足以证明共享的核心代码是合理的。如果是这样，则实际上您有多个单独的产品，应按此类进行管理，而不要在它们之间创建人为的耦合。

我们都知道单元测试是必经之路。但是我们也知道，将它们现实地改造成一个核心是困难的。

扩展功能时可能对您有用的一项特定技术是尝试临时和本地验证现有功能是否已更改。可以这样完成：

原始伪代码：

def someFunction
   do original stuff
   return result
end

临时就地测试代码：

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

通过现有的任何系统级别测试运行此版本。如果一切正常，则说明您还没有损坏任何东西，然后可以继续删除旧代码。请注意，当您检查新旧结果匹配，则还可能会添加代码，分析差异，捕捉的情况下，你知道应该因为预期的变化是不同的，如bug修复。

“大多数情况下，变更不会在团队中宣布，因此错误几乎总是无法预料的”

通讯问题有人吗？为了确保进行适当的沟通（除了其他人已经指出的，您应该进行严格的测试）呢？人们已经意识到他们正在编写的界面将在下一个版本中更改，这些更改将是什么？
并在开发过程中尽快让他们至少访问一个虚拟接口（具有空实现），以便他们可以开始编写自己的代码。

没有所有这些，单元测试除了在最后阶段指出系统各部分之间存在某些不足之处外，不会做很多事情。您想知道这一点，但您想及早，很早就知道，并且让团队彼此交谈，协调努力，并且实际上可以经常访问另一个团队正在做的工作（因此定期提交，而不是一次大量的提交）交付数周或数月（交货前1-2天）后提交）。
您的错误不在代码中，当然也不在其他团队的代码中，这些团队不知道您正在与他们编写的接口搞混。您的错误是在开发过程中，人与人之间缺乏沟通和协作。仅仅因为您坐在不同的房间并不意味着您应该将自己与其他人隔离。

首先，您有一个沟通问题（可能还与团队建设问题有关），所以我认为针对您的案例的解决方案应该侧重于……好吧，沟通，而不是开发技术。

我认为在启动客户项目时不可能冻结或分叉核心模块（否则，您只需要在公司的日程中集成一些与客户无关的项目，以更新核心模块即可）。

因此，剩下的问题就是尝试改善团队之间的沟通。这可以通过两种方式解决：

• 与人类。这意味着您的公司指定了一个人作为核心模块架构师（或任何对高级管理人员有用的术语），他们将负责代码的质量和可用性。这个人将化身为核心。因此，她将由所有团队共享，并确保他们之间的适当同步。此外，她还应担任致力于核心模块的代码的审阅者，以保持其一致性；
• 工具和工作流程。通过在内核上进行持续集成，您将使内核代码本身成为通信介质。这首先需要付出一些努力（通过在其上添加自动化测试套件），但是随后的每晚CI报告将是核心模块的总体状态更新。

您可以在此处找到有关CI作为交流过程的更多信息。

最后，您仍然对公司缺乏团队合作精神有疑问。我不是团队建设活动的忠实拥护者，但这似乎是一种有用的案例。您是否定期举行开发人员范围的会议？您可以邀请其他团队的人参加您的项目回顾吗？还是有时在星期五晚上喝啤酒？