随着移动端近十年的发展越来越多的企业对于app的架构上采用了组件化的方案。在这里大体跟大家聊一下对于组件化的个人经历。

之前本人任职17173的门户app的开发。起初17173是一个很简单的游戏新闻类APP，和绝大多数app一样只有一个project，那时候业务也相对简单，一个project完全可以解决，那时候开发组也就3个人，而且人员也都在北京一个办公室里。但是随着公司业务方针的调整，这个app本身又不断加入了诸如攻略、直播、虚拟商城、资讯、新闻、社区、交友等板块，再加上各类公司统一风格的UI控件、打点、音视频等模块的接入。一个起初以游戏新闻类为方针的app慢慢的变成了一个诸如现在美团、大众点评、淘宝这样的平台类聚合型的超级app。光主app的开发就有10人左右，这还不算上音视频、用户中心、网络框架等非主app的开发人员。人员分布也从北京一个办公室变成了北京两个办公室、福州、深圳多处分部。随之而来的出现了下面相当多的问题：

单一工程遇到的问题

1. 对新员工不友好

我刚进入项目组的时候，整个项目有30多个G，因为每个模块都是相互耦合的，所以虽然只是要跑一个project，但是你要拉下来一堆其他的东西，这些东西在Projec里面的依赖关系还是相对路径依赖，各个文件夹的路径都是不能变更的。我是花了3天，搞了各种环境变量，各种配置才把项目跑通的。因为是第一次进这种大公司，所以当时还觉得好厉害，不愧是大厂。结果现在想想，唉~~~

2. 代码冲突

随着业务模块的增多，主app开发的人员就多达10人，这10个人在一个办公层，而另外诸如用户中心、网络、音视频的则在另外的办公层。每次合代码都仿佛再渡劫，明明我这里能运行，可是到了其他人的环境下就是报错，而且还是那种根本不知道怎么解决的冲突，好的半个小时解决，惨的时候1-2天都是有可能的，好几次只能重新拉代码或回档。

3. 人员分散

因为很多人的办公地点较远，只能通过RTX、QQ、微信、邮件的方式来沟通。每次导致了各种开发进度可能随时在一个点卡死。

4. 迭代速度

前面3点导致了这里要谈的迭代速度缓慢。很多核心模块的开发基本属于牵一发而动全身，只要改了一个小部分，测试的同学就需要全跑一边。而且因为大家开发任务关联度高，很多甘特图排出来后导致，一个权重很高的关键任务卡死了好几个进度（就像是多个线程都在等待一个线程完活儿才能进行）。而往往这种关键任务都是1-2个核心人员开发的，根本无法通过增加人员来达到加快进度的目的，真的就只能干等。很多时候能看到一群人陪着几个人一起加班。明明可以一起愉快地玩耍，现在只能一起愉快的加班。

5. 同质APP

由于后期战略变化，导致了不同游戏要出针对的app，比如针对于WOW的就要出来一个无论咨询、新闻、用户中心、网络、直播、论坛都是WOW的app。明明理论上就是一个换皮app，但是这皮换起来真的是换不动，相信有过几年开发的同学们懂得都懂。

6. 版本风险

由于都是源码级的集成，所以风险根本不可控，人和人都有资格动这个工程的任何代码。想要增加或者删除任何一个模块，那可不是增加或者注释掉几句代码就能解决的，增加还好，删减代码的风险是真的不可控，你是真的不知道你删除的代码里产生什么样的蝴蝶效应。例如，你也许根本不知道一个交易模块中居然还有数据库的代码，这就导致了凡是有老版app的手机，在开启删除交易模块后的app时，数据库加载失败而疯狂奔溃。

组件化引入的难点

然后我们部门来了一个大神，引入了组件化的概念。按照每个代码的功能以及上下文切成一个个模块，每个模块之间仅仅只是依赖关系。逐一的解决以上问题，但是也引入了新的问题：

1. 开发思想变更

组件化后，每个人的面向的开发任务从一个project变为了一个模块，对于开发人员的封装能力有了一定的要求。比较具体的来说更多从面相对象编程变为面相协议以及面相接口编程

2. 文档标准化

每个组件的每次tag都会伴随着一个REAM，每次更改都需要记得更改文档，毕竟一个错误的文档描述杀伤力远比一段逻辑错误的代码。

3. 单个组件开发时间变长

每个组件因为都要为其他组件负责，所以每个组件的开发都需要长时间的斟酌，每个方法的命名是否言简意赅，每个协议的声明是否在单一职责和接口隔离之间做到了比较适中的位置。

4. 脱Model

每个组件内部都有自己的Model体系，但是组件之间如果还是用每个组件内部的Model则还是存在着内聚甚至是组合关系。

5. 组件切割

这个主要是由单一工程变为组件的过程，后面会具体分析。

6. 组件分层

组件和组件之间也是有上下级关系的，高级组件只能调用底层组件，一个优秀的组件框架设计可以将组件下沉，让该组件变得更加通用。如果错误的分层可能导致意想不到的依赖后果。

7. 组件通讯

组件化最为头痛的问题，横向组件之间基本都是通过一个路由来实现解耦。这个路由的设计是组件化的核心问题之一，因为需要考虑注册、易用度、各种数据类型的传输、线程安全、依赖注入、反向依赖等等。

8. precs文件

iOS的组件化不像Android那样有着天然的系统支持，所以这里基本都是依赖pod这个三方实现的。precs的编写也是一个好的组件的前提条件。

分工建议

组件化人员越少越好基本控制到3人左右，因为组件化一个架构方面的重构，人越多思想越多样化，这是重建架构所需要避免的。然而组件化也是一个需要估算人天的事情。繁杂的工序会打乱原有的架构设计，也会让原本的计划难产。整个过程需要产出的并不仅仅是多个组件，而是工程以及组件化完成的UML图。每个组件的切割都应该有明确目的的切割。

总结

通过上面的分析可以来也可以来看看，各位当前的项目是否真的适合且需要组件化。

虽然从上面看起来组件化有着很多的缺点，但是这些缺点和上面提到的问题所带来的的麻烦还是值得的。