iOS开发

谈谈组件化的历程

2018-05-14  本文已影响77人  _ivanC

组件化是一个不可避免的阶段，个人认为也是一个越早越好的阶段。特别在一个公司内的产品越来越多的时候，显得尤为重要。

什么是组件化

组件化的字面意思，是代码上可复用的结果，而实际上组件化远不止这个层面。

在没有组件化的时候，每个项目都是各做各的事情，包括一个组内也是存在重复造轮子的行为，等到需要抽离独立模块的时候，又发现耦合过大，花费大量人力来解耦或者重构，甚至不了了之。

新项目的快速成型

立项 ---> 确定需求 ---> 搭建主工程框架 ---> 引入需要的组件 ---> 补充没有的组件 ---> 成品

在一定的积累下，一个公司内部的新产品开发，都可以快速的搭建起一个拥有公司基础业务组件的框架，专心做差异的业务开发，而无须重新花费力气重新开发这些基础功能，例如一些性能监控，数据上报，测试框架等。

研发思维于流程的质变

组件化并不局限于基础底层的东西，业务逻辑，界面封装都可以成为一个组件，例如通用下发配置，相机相册界面等，都可以成为大组件化的一个积累过程。

在这样的环境下，研发的开发流程会变成下面这样

获得需求 ---> 前期分析和设计 ---> Coding ---> 组件化（如果可以） ---> 完成开发

区别在于，在组件化的大环境下，大家在开发前期，会思考这个需求是否可以成为一个通用方案，而进行一些前期的分析和设计，可以的话，就会从中找到可以组件化的部分，成为一个独立模块。即使不能组件化，也会对于后续这个模块的低耦合方面有所贡献，引导大家面向接口编程，保持下层稳定性。

潜在的激励

每个研发都希望自己的代码得到认可，组件化可以潜在的推动这个事情。从组内组件化，到跨项目通用，到公司内公用，最后发展成对外开源，是一个不断鼓励代码优化和维护的过程。

探索之路

早期的开发可能都会经历过这么几个阶段，现在或许直接就到了最后的形态，再往后就在于是否坚持了。

以下列出了几种我经历过的工程形态，有些或许现在还是这样，我们可以顺着理一下，这里都是基于iOS的开发来讨论。

一个工程走天下

在早期，或者现在还有些项目，一个app只有一个主程序，所有代码按照文件夹来划分，实际上都在一个target上，很多开发会觉得很方便啊，这样有什么不好呢？

当然也不能一棍子打死所有案例，有些app就是简单，没必要那么复杂化，但是怎么也会有一些自定义的基础类封装吧，统一管理出来是个好习惯，说不定那天会感激自己的多此一举的

至于公司级别的app，基本上就不会简单到那个地步了，至少我个人是这么觉得的。

多工程模式

多工程模式下，一般有点规模的一个功能，都会独立成一个工程，放在主工程下，成为一个子工程，主工程依赖这个target即可。

多工程和多文件夹的最大区别在于

这里的好处是没有异议的，但是怎么很好地解决依赖问题是一个探索的过程

0x1 拖拽文件

从早期我们遇到一个子工程，需要一来到另外一个子工程的文件的时候，第一想到的办法就是把那些文件的.h拖到这个工程来，然后发现这个.h又依赖了另外的.h，直到把所有头文件都拖进来了，总算完事了。

但是突然有一个文件上的改动，这个行为可能要重新做一次，这就很恐怖了。

0x2 子工程化依赖

既然我们已经用工程化的行为来模块化了每个业务或者说每个功能集，为什么不还局限于对某个文件的依赖呢？

你依赖一个业务里面的文件，很大概率你就会用到这个业务里的其他文件，既然这样，我们就把文件级别的依赖升华到工程级别的依赖。

也就意味着我们不再一个文件一个文件的拖，而是整个子工程拖到自己的工程下面，那么这个工程就可以访问整个子工程的公开文件了，何乐而不为呢？

0x3 统一工程化依赖

但是我们发现，依然没有完全解决这个问题，想象一下，如果某个工程被其他很多工程都依赖了，而这个工程位置变了，一个基础模块工程，一下子需要放到很多很多工程下，这个操作也是很难受的。

我们想了一下，创建了一个Bridge工程，所有工程都依赖Bridge工程，同时所有工程都是Bridge工程下的子工程。

乍看之下好像有点死循环，其实不然。

这种情况下，为了方便大家，还创建了一个工程模板，统一标准创建，且附带好所有脚本，唯一需要做的，就是把自己拖进Bridge工程的依赖当中。

0x4 脚本时代

说到底，Bridge工程 开始还是需要人为拖动，且不利于新人理解

我们回归到最原始最本质的问题上：可以使用目标.h文件

清晰了这么一点就好办了

（可能很多人觉得这只是一个framework的事情，但是那时候还没有framework，而且目前一些老项目说不定还在支持iOS7）

脚本能带来的好处是很大的，除了方便了很多以外，甚至可以做到任何交叉循环依赖，在每个子工程上可以说用的风生水起了。

但是埋下的问题也是很可怕的

Workspace模式

0x5 Pod的到来

Pod的规范化可以说带来了一个最终的项目工程形态（当然也有些公司有自己更好的一套方案），主要得益于：

对于Pod的模式和使用上，这里就没必要多说了，可以到Cocoapods的官网了解详细的内容，也可以Google一些插件定制化的东西来满足特定的需求。

这里先回答一个疑问，Pod毕竟也不是很晚期的东西了，为什么早期或者中期不直接开始引入这个模式呢？

一个客观原因是，在当时Pod刚起步，或者说还没有到现在这么普及，我们还在观望和不熟悉的阶段，的确是有点踌躇，通俗点说，对于陌生的东西，就是有点怂。

另外一个是历史原因，我们虽然看到前面几个阶段有很多不规范不成熟的地方，但是它们在当时的确是一个相对较佳的方案，我们来分析一下为什么：

阻力是什么

从前面的分析看来，不难发现，组件化的阻力从来不是技术上的，而是在于流程上的。

从技术层面上分析，组件化无非就是

阻力从来都出现在流程上

组件化的推进，毕竟不是一个组的事情，也不能局限在一个部门上。在所有方案都确定好的时候，你发现需要跨团队跨部门跨子公司来沟通的时候，才是真正的阻力。因为每个部门每个组的情况都不一样，他们有着各自的项目压力和技术方向，更有着不一样的想法。

如何推进

推进的过程，我个人觉得是个艺术活，论外交手腕的重要性（会心一笑）

因为技术方案都确定好了之后，剩下的技术手段都是苦力活，真正花时间的可能都是交际手段

这个过程如果是从上往下推动的话，显然比从下往上要容易得多。

最后

组件化显然是一个不可避免的趋势，如前面提到的，我个人认为是越早开始越好，对于开发人员的思维定性来说，一旦长期没有这个概念，乱糟糟的代码是不可避免的，也是会互相传染而泛滥。

虽然很多产品现在都是不在乎实现，但求无错不崩溃的态度，显示也不是一个可持续发展的做法，一定规模的公司更是要避免这种短期成品的行为。

也有一部分公司觉得需要的人力很大，在业务重压之下没有任何资源来做这件事情。我个人认为也是一个比较极端武断的想法，组件化并不要求一次性到达一个完美的阶段，它和业务一样是一个重复迭代优化的过程，在即使最糟糕的情况下，我也可以把所有明显的独立模块大集合先抽离出来，不要求代码有任何改动，只是单纯的抽离，达到一个可用的阶段即可，这样就可以先让全公司的项目，先用上同一份代码，无论是资源的释放，还是逻辑上的统一，都是一个非常好的开端，总之代码的收拢越早越好。

一些公司也有自己的SDK组，这些其实是组件化的前身，如果能进一步去演进和统一操作，相信会得到更多的好处。

以上仅代表本人个人想法，欢迎吐槽和交流

上一篇下一篇

猜你喜欢

热点阅读