javascript - AngularJS 架构：单仓库或多仓库

我正在研究将巨大的单体 SPA (AngularJS) 代码拆分为多个存储库的可能性。我们是否应该这样做？好处和陷阱。

理念：

该应用程序包含多个单独的功能（用户管理、分析、事件管理）angular.module。

想法是将这些不同的模块拆分到自己的存储库中，并拥有某种主存储库，在部署之前将所有部分放在一起。

原因

我们的应用程序现在很大，而且只会变得更大。此外，致力于它的开发人员的数量正在增加。

其他原因：

发现

我读过微前端架构正在成为一种越来越流行的构建大型应用程序的方式。

另一方面，这会分散文件，使 fx.js 变得更加困难。重构共享模块。看来fx。Facebook 和谷歌有单一的回购。

经过几天的研究，我仍然很痛苦。我看到了单存储库和多个存储库的优势。

我还研究了git submodule将功能“导入”到主存储库中的一种方式。这是我最不喜欢的选择。另外，我以前从未听说过，git submodule所以如果有人在这方面有经验，请随时加入。

最后，最重要的问题是：是否可以将一个 AngularJS 应用程序拆分为多个存储库？

标签： javascriptangularjsarchitecture

处理单体代码库

我也有同样的问题，随之而来的内部冲突。我找到的最好的答案是这个。“你和你的团队是回答这个问题的最佳人选。” 我知道这与微前端将统治世界之类的炒作背道而驰，但这是事实。这就解释了为什么有些人使用单体应用并像 Facebook 一样真正成功，而另一些人则使用微前端获得相反的结果，然后获得成功。

管理大量代码的唯一真正问题是人为问题，而不是技术问题。所以这是一个社会问题。当然，技术方面的事情会随着这个决定而改变，但归根结底，你只是改变了程序员和这个代码库之间的人机交互。

那么为什么你的团队最有资格做出这个决定。你比我们其他人更了解你的团队和企业文化的社会动态。

当我做出这个决定时，我问过自己这些类型的问题。

团队如何协同工作？

你的团队是如何训练的？

你的团队有多灵活？

团队和团队成员之间的沟通有多清晰和开放？

我会回答这些类型的问题，并继续使用像 Facebook 这样的案例研究，它证明了在单体架构上团队的规模并不重要，但你如何在单体架构上合作并以此为基础做出决定。