零散项目的管理问题一直是前端工程领域的一大痛点，大型前端项目更是如此。与客户端项目基本一个主体仓库不同，前端项目粒度小且分散，每个项目至少有一个代码仓库，仓库量膨胀迅速，管理起来异常麻烦。仓库量膨胀带来的另一个问题是不同项目的代码架构各自为战，大量重复造轮子，效率低下且难以维护。
在过去一年中，本人也参与了好几次前端业务交接，每次交接动辄十几个仓库，多的甚至能达到好几十个，查找代码在哪个仓库都成了一件体力活。
大型前端项目如何做好代码仓库管理，并在此基础上实现代码架构的融合呢？本文尝试给出一个通用的解决方案。
一、大仓化
大仓化，简而言之就是把所有项目的代码都放在一个仓库下管理。当然一个仓库并不仅仅意味着在把代码在物理上放一起，更代表着基础设施、基础代码的沉淀与复用。
大仓说起来简单，实际操作起来并不容易。前端领域技术栈广，不同项目之间产品形态千差万别，技术选型也不尽相同，强行放在一个大仓下未必合适。一般来说我们可以做如下准备
- 清理无用仓库，合并零散仓库。先过滤一轮，降低复杂度。
- 梳理相似项目。比如按照 移动项目/PC项目/跨平台项目 或 toC项目/toB项目 来分，形成 N（N<5） 个项目集合，针对每个项目集合构建大仓。
- 条件成熟时，全部合并至一个大仓。（取决于当前的工程基础设施是否足以支撑真正意义上的单体仓库）
总结一句话，就是 基于相似产品形态的项目构建大仓 。大仓的建设，可以为后续的架构融合与代码复用打好基础。
二、架构分层
大仓化之后，多个项目仓库已经实现了物理上的统一，同时也能实现基础设施的复用。但如果想把大仓效果发挥到极致，还需要做更合理的架构分层，避免大仓越来越“大”，逐渐沦落为代码大杂烩。
如何做架构分层呢？一般来说可以按照如下层次关系：
- 基础能力：工程基础设施，CI/CD 基础流程等。
- 通用基础层：业务无关的基础组件。
- 业务基础层：业务相关（同一项目集合内通用）的基础组件。
- 业务层：项目的具体业务。
在 基础能力-通用基础层-业务基础层-业务 的架构分层之下，需要逐渐培养代码提交者的架构分层意识，提升技术素养，增强防劣化能力。
三、组件化
复用 是软件工程的核心，组件化 是达成复用的必经之路。任何项目任何技术栈都会做组件化，也有相当多的组件化实践文章，这里也不赘述组件化的优点，方案之类，只是想从宏观角度阐述下前端复杂项目怎么去做组件化。
基础设施
首先明确组件化要解决哪些问题。
- 找不到组件。不知道哪里可能会有想要的组件，费这么大力气不如新写一个。
- 找到了组件，但不好用。其他业务里有个组件，但是耦合了些业务逻辑，必须改造下才能用；或者组件文档不清晰不知道具体啥效果，得花时间去测试。对别人不放心，不如新写一个。
- 新写组件太费劲。新写组件要去独立的组件仓库里开发部署，业务里再引入，每次更新也是同样的流程，还不如直接在业务里写来的快。
其实就是 组件治理， 组件发现 和 组件开发 的问题。如何解决呢？并不复杂
- 建设独立组件仓库或大仓，与业务代码隔离（一旦揉在一起就很难写出通用的组件）。
- 借助 dumi 、 storybook 等工具实现组件的可视化与文档化。
- 搭建组件工具链，通过 CLI、CI/CD 等基础设施实现组件的快速开发、发布、集成。
组件分层
并不是所有的组件都是基础组件，真正提升业务开发效率的，其实更多是耦合了一定业务逻辑的业务组件。但基础组件和业务组件不是互斥关系，而是层次依赖关系。
从组件分层复用上，可以把组件分为
- 基础组件：业务无关的基础组件，包括UI组件和功能组件。
- 模块组件：对基础组件的封装，包含部分业务逻辑。可依赖基础组件。
- 页面组件：跨业务通用页面，包含完整业务逻辑，支持业务简单配置。可依赖基础组件和模块组件。
这样就形成了 基础组件 - 模块组件 - 页面组件 的组件分层架构，使得组件更加灵活。
总结
通过大仓建设实现代码一体化，通过架构分层实现代码融合，通过组件化实现代码复用，任何复杂项目都可基于这套解决方法实现架构融合。