解构中：Shopify的巨石状态

Ruby on rails是一个很棒的框架，可以快速构建用户和开发人员喜爱的漂亮的Web应用程序。但是如果应用程序成功了，通常还会有持续的投资，从而带来额外的功能和增加整体系统的复杂性，Shopify的核心整体拥有超过280万行Ruby代码和50万个提交。Rails没有提供模式或工具来管理固有的复杂性并以结构化、有界的方式添加特性，这就是为什么在三年多前，Shopify成立了一个团队来研究如何使我们的Rails整体更加模块化。我们的目标是通过创建更小的、独立的代码单元(我们称之为组件)来帮助我们扩展以适应不断增加的系统功能和复杂性。我们的愿景是这样的：我们可以更容易地将新开发人员安排到与他们直接相关的部分，而不是整个整体。不是在整个应用程序上运行测试套件，而是在受更改影响的较小组件子集上运行测试套件，使测试套件更快、更稳定。与其担心对我们不太了解的系统部分的影响，我们可以自由地更改组件，只要我们保持其现有合同不变，从而减少功能实现时间。总而言之，开发人员应该会觉得他们正在开发一个比实际小得多的应用程序，自从我们上一次分享让我们的Rails单块变得更加模块化以来，已经过去了18个月。在过去的两年半时间里，我一直致力于模块化工作，目前在一个名为架构模式的团队中工作。我将列出我的团队工作的现状，以及如果我们现在重新开始的话，我们会做一些不同的事情。现状问题我们通常坚持“解构巨石”中描述的原始想法，但几乎所有的细节都发生了变化。我们取得了持续的进展，但重要的是要注意到，做出这种规模的改变需要临界数量的贡献者在思维上进行重大转变，这需要时间。虽然我们远未完成，但我们已经收获了工作的好处。对我们如何编写代码的附加约束在整个组织中引发了深入的软件设计讨论。我们看到开发人员的心态发生了转变，更加注重模块化设计。在进行更改时，开发人员现在更加意识到对整体整体设计和质量的影响。这意味着，新的功能实现现在更多地改进了现有代码的设计，而不是降低现有代码的设计。最近几年接受大量重构的部分代码库现在更容易理解，因为它们与系统其余部分的关系更加清晰。我们自动对组件的异常进行分类，使团队能够对它们采取行动，而不必深入挖掘整个整体有时嘈杂的异常流。由于每个组件都由一个团队明确拥有，所以像Rails升级这样的整个代码库琐事很容易分发和协作解决。Shopify的主要部件运行在最新的、未发布的Rails版本上。代码库区域的明确定义所有权是使我们能够做到这一点的因素之一。到目前为止，我们了解到我们的主要整体是地球上最古老、最大的Rails代码库之一，至少自2006年以来一直在不断开发，目前有数百名开发人员正在添加功能。这种规模的重构需要与较小的工作完全不同。我们了解到，所有大规模的更改都是从理解和影响基层的开发人员行为开始的，从整体架构的角度出发，通过谨慎地应用工具，并意识到涉及的权衡了解开发人员行为一个单一的集中式团队不可能通过对抗数百名添加功能的开发人员的势头来实现更改。此外，它也不能预测所有的边缘情况，并且在应用程序的所有领域都有上下文。一个团队可以进行大规模的简单更改，也可以进行小规模的复杂更改。然而，要将大型整体模块化，我们需要进行大规模的复杂更改。即使一个集中的团队可以做到这一点，一旦团队将重点转移到其他事情上，设计也会降级。这就是为什么对正在积极工作的系统进行根本性的架构更改在很大程度上是一个人的问题。我们需要改变普通开发人员在代码库上的行为。我们都需要共同迭代地使系统朝着设想的未来发展。开发人员是系统不可或缺的一部分。斯坦福大学行为设计实验室的创始人B.J.福格(B.J.Fogg)开发了一个思考符合我们经验的行为的模型。该模型表明，要使行为发生，需要具备三件事：能力、动机和推动力。Fogg行为模型作者：BJ Fogg，PHDIn