1.组件化的目的是什么？

最近一两年很多人都想在项目里面搞组件化，觉得搞组件化好，却鲜有人知道组件化好在哪里？组件化的目的是什么？个人觉得组件化主要有两个目的：

1.实现项目代码的高内聚低耦合；

2.方便多人多团队开发（这就是大团队为什么那么热衷于组件化的原因，对开发的效率的提升是十分显著的）。

2.我的项目组件化应该做到什么程度？

个人认为组件化的程度取决于项目的大小，当一个项目一个人可以轻松开发和维护时，只需要项目架构保持如下图即可：

把基础层的部分抽成组件，用cocoapods来维护，实现基础层与表现层，业务层去耦合，业务层与表现层依然耦合。

当项目变的越来越大，功能模块越来越多，需要五到十几个人维护的时候，就需要明确组织里的每个人负责的功能模块，在代码层面也需要业务层和表现层区分开来，业务层和业务层之间也要区分开来，表现层与表现层之间也要区分开来，要想做到这些，需要做很多的工作，首先要划分好功能模块，保证一个模块的表现层和业务层代码在一个文件夹；然后一个模块下的表现层和业务层逻辑要有一个明显的区分；再引入一个中间件比如CTMediator，作者自己写的中间件基于CTMediator的ZZRouter，中间件用cocoapods来维护；每个模块根据中间件提供外部调用的接口，本模块调用外部模块，一律使用中间件来调，实现模块间的去耦合。中型项目的理想架构应该如下图：

中型项目理想架构

当一个app成为超级app需要多个团队共同协作开发的时候，对组件化的要求又更高了，这个时候需要实现模块的独立编译，以及在主项目中的静态和动态加载，同时又要保证模块间的通信，正在完善的BeeHive就是奔着这个目标去的。

3.组件化实践中的一些个人感悟

我们项目组件化方案是在去年11月底定的，最先在一个14年开发的老项目中实施的，采用的是上述的中型项目的架构，实施过程中的工作量超乎了我们的预期，这个老项目本身的基础层的维护做的不错，我们把自己做的基础组件做成私有pod来维护，过程比较顺利；再然后就是进行模块划分，当时按vc和service的最小粒度进行了划分，整理结束后发现有上百个之多，按依赖关系连起线来看的人头皮发麻，如果按最小粒度划分显然不现实，最后决定把关联度很高的小模块放到一起组成一个具体的模块，这个模块既提供vc也提供service，最后缩减成不到20个模块，这部分工作从头到尾花了不少时间；等模块划分完，确认好模块负责人后，我们开始按照CTMediator的target-action方式让每个负责人写target和category，这个时候很多负责人因为对这套体系的不了解出了很多问题，只有反复的去沟通交流，制定规范，慢慢的大家熟悉了，问题就少了；同时由于一些接口传参过多而采用字典传参，key为硬编码的方式，经常发生接口提供方改变key没有及时通知到调用方而出错的问题，最后规定接口提供方的注释一定到精确到每个key表达什么意思，有改动立即通知调用方。最后整个组件化搞下来，导致提测时bug增加了不少。但是等到后面我们对两个新项目组件化的时候，因为大家多组件化都又了一定的理解和认识，就很少因为组件化出现bug了。