Composer 建议的内部包方法答案

【问题标题】：Composer suggested approach for internal packagesComposer 建议的内部包方法
【发布时间】：2013-02-20 11:49:20
【问题描述】：

先了解一下背景

我们公司是一家只有四名开发人员的小型初创公司，它正在开始将我们的产品重构为可重用的模块，以简化开发过程、提高生产力，并且在此过程中，我们希望在合适的地方引入单元测试。

与小型初创公司一样，我们不能浪费太多的开发时间，但正如我们所见，这对于我们的中长期业务成功极为重要。

目前，我们有两种最终用户产品。两者都是建立在我们自己内部业务层之上的 Laravel (PHP) 应用程序，主要由 webservices、restful apis 和一个庞大的数据库组成。

该业务层为这些产品提供了大部分数据，但每个产品的使用方式完全不同。除了维护和改进这两个几乎完成的产品之外，我们计划在不久的将来构建其他产品。

为此，我们打算将这些（以及未来）产品的通用逻辑抽象为可重用和解耦的模块。显而易见的选择似乎是 Composer，即使我们对此知之甚少。

现在是真正的问题

我想就如何以测试驱动的方式开发内部包提出其他意见。每个模块应该是一个包含自己的单元测试并需要它的依赖项的 composer 包，还是应该构建一个包含每个模块命名空间的单个包？

为了澄清一点，我们希望有一个 CurlWrapper 模块，这在我们的 InternalWebserviceAPI 模块（以及其他一些模块）上是必需的。

我个人喜欢为每个模块提供完全独立的包并声明对 composer.json 的依赖项的想法，这将在精神上强制解耦，并允许我们有一天将其中一些包作为开源发布。它还可以简化对这些模块的重大更改，因为我们可以将它的版本冻结在需要更新的依赖项上。

不过，我也认为这种分离可能会增加很多复杂性，并且可能更难维护和测试，因为每个模块都需要独立成一个项目，而我们没有那么多人力来跟踪这么多小项目。

Composer 真的是我们问题的理想解决方案吗？如果有，哪个推荐：单包还是多包？

编辑 1：

我想指出，这些模块中的大部分将是：

【问题讨论】：

我目前正在考虑为项目采用类似的模式。我的问题是一样的，所以我想知道你是怎么做的。理想的解决方案我想要 Wouter 下面提到的那个，但正如您所知，它在集成位方面增加了一层复杂性。但从长远来看，它是一个健全的架构。虽然权衡将是开发人员的时间，因为这会有点耗时。

【解决方案1】：

使用单个包的替代方法：为每个子项目使用separate composer.json files。

这样做的好处是让您可以将所有库保存在同一个存储库中。在重构代码时，您还可以通过子库对自动加载和依赖项进行分区。

如果您想将库拆分为自己的版本包，您可以进行最后一步并将其签入自己的存储库。

【讨论】：

【解决方案2】：

是的，composer 是要走的路，我建议你使用单个包。

您不知道何时需要这些模块。最好创建许多单个包并能够将它们全部（或单个）包含在内，而不是创建大包并且当您需要其中的一些类时需要花费更多时间将包分解为多个包。

例如，参见 Symfony2 项目。这是全栈 Symfony2 框架所需的大量组件，但您也可以在自己的项目中使用一些组件（就像 Drupal8 正在做的那样）。此外，Symfony2 获得的包越来越多，拥有小包似乎很有用，以至于人们花时间将一些大包分解成碎片。

【讨论】：

感谢您的回答，Wouter。事实上，Symfony 和 Laravel 架构是我们怀疑的主要动机，它们在构建时考虑到了模块化包，效果很好，但它们不仅由专门的开发人员维护，而且由整个社区维护。或者主要担心的是，这种架构可能会过度使用，并且会占用我们小团队过多的维护时间，这些小团队分散在这些产品和为它们提供数据的底层服务之间。