我正在做一些研究，研究是否可能将巨大的整体式SPA（AngularJS）拆分为多个存储库。我们是否应该这样做？好处和陷阱。
想法：
该应用程序包含多个功能（用户管理，分析，事件管理），这些功能是单独创建的angular.module。
想法是将这些不同的模块拆分成自己的存储库，并拥有某种主存储库，该主存储库将在部署之前将所有组件放在一起。
原因
我们的应用程序现在很大，而且只会越来越大。另外，从事此工作的开发人员数量也在增加。
其他原因：
发现
我已经读到micro frontend架构正成为构造大型应用程序的越来越流行的方式。
另一方面，这将分散文件，使得在执行fx时更加困难。重构共享模块。看来，FX。 Facebook和Google拥有单存储区。
经过几天的研究，我仍然感到恐惧。我看到单存储库和多个存储库都具有优势。
我还研究了git submodule作为将功能“导入”到主存储库中的一种方法。这是我最不喜欢的选项。另外，我之前从未听说过git submodule，所以如果有人在该领域有经验，请随时加入。
最后，最重要的问题是：甚至可以将一个AngularJS应用程序拆分为多个存储库吗？
答案 0 :(得分：2)
处理Monolith代码库
我遇到了相同的问题，即随之而来的内部冲突。我找到的最佳答案是这个。 “您和您的团队是回答这个问题的最佳人选。”我知道这违背了Micro FrontEnds之类的大肆宣传，但它是事实。这就解释了为什么有些人会像Facebook那样使用巨石并获得真正的成功，而另一些人选择Micro Frontends却获得相反的结果，然后变得成功。
管理大量代码中唯一真正的问题是人为问题而不是技术问题。因此，这是一个社会问题。当然，技术上的事情会随着这个决定而改变，但是最终，您只是在改变程序员和此代码库之间的人机交互。
那么，为什么您的团队最有资格做出此决定。您比我们其他人更了解您团队的社会动力和企业文化。
做出这个决定时，我问自己这类问题。
团队如何合作？
您的团队如何训练？
您的团队有多灵活？
团队与团队成员之间的沟通有多清晰和开放？
我会回答这些类型的问题，并继续使用Facebook之类的案例研究，事实证明，一个整体上的团队规模并不重要，但是您如何在那个整体上一起工作并基于此做出决定。