针对iOS组件化的_前言

非组件化

“****一个项目一个工程****”

之前一般的做法，或是学完教科书版的思维。都是这样子的，开发一个项目，使用xcode创建出一个工程(file→new→project)。然后：

1 根据不同模块创建出不同的模块文件夹；

2 根据mvc模式(或mvvm)，在模块文件夹下创建出View、Controller、Model、（ViewModel）文件夹；

3 根据模块所需的公共类，创建出公共文件夹，在开发过程中把一些通用的工具类、视图类扔在公共文件夹中；

4 创建一个文件夹装纳各种第三方的sdk或.a，命其名(如lib)，因为Cocoapods在业界知名度，很多人使用了Cocoapods集成各种pod库；

5 创建一个资源文件夹，容纳所有的资源文件(较多的是图片)；

前期很多人会认为自己能够完成以上几点，就完成了项目架构的搭建。然后后续业务的进入，就在不同文件夹下添加代码。

当然，这些路我们都走过。

组件化

一切皆组件，****“****一个组件一个工程****”

业务模块可以做成一个组件，可以做一个用户中心的组件，也可以做一个用户注册的组件；

UI部件可以做成一个组件，可以做一个时间选择器的组件，可以做一个定制按钮的组件，可以做一个数字加减器的组件，也可以将这些UI部件集合在一起做成一个UI组件库；

工具方法可以做成一个组件，可以做一个字符串加密的组件，可以做一个数据存储的组件，也可以将这些方法集合在一起做成一个工具组件库；

对比：

非组件化的做法有一些不好的地方，比如：

1 大团队的多人开发效率低下；

2 业务复杂繁多时，业务代码在工程中混乱，难以维护；

3 不便于公司对不同业务代码的权限控制；

4 不便于公司对员工工作质量的评价；

缺陷，在此不穷举，对这四点的展开说明。

大团队的多人开发效率

大团队：不同人有不同的理解，不同行业也有不同的理解。针对iOS，我认为超过6个人，团队比较大了。

非组件化开发，多人在同一个工程里写代码，最显眼的问题就是代码经常发生冲突。我们也曾为此努力过，比如说：1、划定不同人开发不同的功能(“从源头上解决”)；2、学习培训总结代码冲突解决方案(“解决问题”)。不管如何针对不同功能划分不同开发人员，都难以避免工程配置文件的冲突。对于代码冲突，当然是避免冲突要好，不断地去解决源源不断的冲突是一件让人头痛的事。但是，若使用组件化开发就不同了，会大大降低代码冲突的可能性，开发人员在某个组件工程里单独开发，“环境清静，无人打扰”。当然，若是多人合作开发某个组件，也是有代码冲突发生的，但是这样牵涉的面积就会小很多，发生的可能性也会小很多。

非组件化开发，随着需求不断进来，同一个工程的代码体积在不断增大。每个人在调试一段代码时，时常完成编译就需要花费很长时间。然后完成编译之后，可能有需要点击很多地方（有很深的业务/视图层级），才能到达需要调试的界面，从而所需要依赖的业务就比较多了。我们也曾为此努力过，比如说：在Debug模式，开发者可以通过一个设定值，使得App启动之后直接进入到所要调试的视图，但是仅限于调试静态界面。不管怎样，编译整个app的时间还是需要花费的。

业务复杂繁多时

业务繁多，在采用非组件化开发时，经常会有业务A依赖业务B，业务B依赖业务C，业务C依赖业务A。问题就是代码耦合度太高，难以随着业务做修改，或者难以删除一些看似垃圾。拔出萝卜带出泥的事，我认为有尝试解耦的人会深有感触。久而久之，依赖愈来愈重，垃圾代码越来越多。

既然解耦麻烦，我们就应该避免耦合的发生。采用组件化思路开发，可以将A、B、C拆成3个组件去做，3个组件相互不要有任何依赖关系，组件之间的依赖(或称传参)扔给[中间件]去做。

这样组件就只需重点关心提供的功能，以及如何实现。这些都是组件内部的事。

业务需求多的时候，按照组件的思维，把某一个需求当成一个组件或是拆分成多个组件来开发，是便于管理分工的。

公司对业务代码的权限控制

若是公司要业务代码做权限控制（至于为什么要做代码权限控制，这里不多说）

使用非组件化的模式，一个项目一个工程，我目前对git的了解，还不知道能有什么好的方案去开展。

但是，使用组件化的模式，一个组件一个工程，就不一样了。这种情况下每一个工程就是一个代码库，就相当于你可以对每个组件添加权限控制。当然，你可以添加不同的权限。

公司对员工工作质量的评价

使用组件化模式开发，其实不同人负责的组件是明确的、“隔离”的。这样员工负责开发的组件质量可一定程度上反应出其工作质量的。

但是使用非组件化模式开发，就不同了。因为在一个工程下开发，员工A的代码很有可能影响到员工B的代码，这样就会导致你在评判一个人的工作质量时，就需要投入更多的时间或更多的精力去分析。

总结：组件化，耦合度低，易测易调试，益团队管理。