多模块设计本地依赖关系的最佳实践

Question

这个问题可能已经问过了，如果是的话，可以自由地链接到答案。我正在寻找一个现代而有效的方法来解决一个常见的问题。我有一个项目，有一个主要模块，A，这取决于另一个模块，B，我单独开发。这个模块有2-3 (C)它所依赖的其他模块，每个模块也属于我。有些人感到舒服的定位所有模块在一个svn或Git回购。我的经验和直觉告诉我，每个模块属于和个别回购。我目前面临着一个NodeJS/电子项目的两难处境，但问题/解决方案肯定与技术无关。虽然我对节点中的本地模块知之甚少，但我更熟悉这些概念。我只是在绞尽脑汁如何把我所学到的东西最好地应用到我目前正在做的这个项目上。

我将在下面迭代这两种方法的优缺点，从我的17+多年经验中可以看到这一点。我感兴趣的是，其他人是如何解决这个问题的，在当今时代，完全独立的模块是可行的吗？在管理本地依赖关系方面有什么新的技巧，我多年来一直忽略这些技巧吗？

在一个回购

中

优点：

• 所有的东西都可以很容易地编译/调试成一个完整的程序，采用经典的思维方式。
• 在启动主模块时，单个模块中所做的更改立即可见并表示出来。一切都是“联系”在一起的。
• 初级-中级工程师入学门槛较低。

缺点：

• 由于责任界线模糊，项目凝聚力受到损害。(太容易将代码从被告链接到依赖关系&反之亦然)。
• 必须考虑到更慢、更复杂的构建作为附加逻辑，以正确的顺序和适当的方式编译每个模块。

单独repos

优点：

• 更好的凝聚力。明确划分责任范围
• 即时/即时可重用性。(为了证明该模块有效，您必须在其依赖模块之外测试它，该模块从一开始就强制重用。)
• 更小、更简单、可管理的构建。每个版本构建一次依赖项，主项目只需要声明其依赖项，而不是构建每个依赖项。

缺点：

• 在模块依赖项中迭代更改的额外复杂性。在主模块中运行之前，必须构建一个依赖项&释放(或半释放)。
• 在调试中添加‘l复杂性’。根据技术栈和组装整个应用程序的方法，您不能始终使用这种方法进入依赖源。
• 要求更多的纪律，更高的门槛进入初级-中级工程师。

我提到了在调试过程中无法进入代码作为一个骗局，但这并不适用于所有源总是可见的JavaScript。然而，当模块被外部化时，我仍然面临在IDE中设置调试的挑战。

Answer 1

我的两分钱：

在共享项目上使用单独的存储库.

换句话说，如果一个项目被多个其他项目使用(或者打算在多个项目(即库)中使用)，那么它就属于自己的存储库。

在我目前工作的地方，我们正遭受着这种痛苦。下面是当前的谈话内容：

ME:作为一个策略，项目不应该直接从源代码存储库构建吗？她:是的，他们应该。但是我们没有一个正常工作的CI服务器，您不能期望在没有此规则的情况下强制执行此规则。我:难道我们没有其中之一吗？她:是的，但是它在云服务器上，它不能访问我们保存最新构建二进制文件的共享驱动器。我:那我们为什么不直接让CI服务器为我们构建这些二进制文件呢？她:真的，我们应该采用项目引用，而不是二进制引用。这样，我们就可以确定每个项目都有它需要构建的所有东西。ME:如果您让我这样做，您将要求我对包含公共库的主存储库具有依赖关系。该存储库在一个解决方案中是39个单独的项目，大小为1G，它不会从当前的存储库构建在我的机器上。为什么我们不把公共项目分割成他们自己的存储库呢？她：>_<