低调看直播体育app软件下载
本篇文章主要介绍了" iOS组件化拆分之业务与拆分并行开发"，主要涉及到方面的内容，对于IOS开发感兴趣的同学可以参考一下：
一、前言：公司业务代码耦合性严重，需要进行组件化拆分，但是业务需求在不断的涌来。一方面业务开发不能停，另一方面老代码还是要拆分。产品经理提出业务任务，程序员提出...
一、前言：
公司业务代码耦合性严重，需要进行组件化拆分，但是业务需求在不断的涌来。一方面业务开发不能停，另一方面老代码还是要拆分。产品经理提出业务任务，程序员提出组件化拆分任务，为了避免这场大战，如何可以兼顾两者呢？
图1：
二、思考过程：
2.1 模式一
建立组件，然后在新组件里面重写呗？
这种方式如果是新业务可以，但是面对老业务，可能最初的开发人员已经离职，可能代码都没有注释，会有很大的风险。重写代码，时间会特别长，原本开发一年的APP，怎么可能快速重写？测试怎么可能快速测试完？岂不是又要花费一年？不仅开发周期长，并行的业务需求怎么办？显然这个并不适用于业务与拆分并行开发的情景下。
2.2 模式二
建立组件，然后一个一个文件往组件里面移动。
这种方式，我们会发现，移动一个文件，然后就会有好多报错引用，把引用的文件移动进来之后，移动进来的又有其他的引用。文件间的相互引用问题会让我们无法将程序编译起来。并且模块内容不完整，看不到尽头。
2.3 模式三
建立组件，然后把这个模块的文件夹移动到组件工程中去。减法拆分。
把主工程代码也都移动到组件工程中去。程序可以独立编译起来，然后我们一个一个删除主工程的其他代码。删除一个我们编译一个。这样减法拆分我们可以保证每次程序可以运行起来，但是还是会面临无法和业务需求一起开发的情景。
2.4 模式四
不建立组件，我们只在主工程中建立新文件夹，按模块拆分。
此时让业务并行的开发人员在另一个独立文件夹中开发业务，不影响拆分文件夹。
这个模式指的是我们还是在主工程下拆分，只是我们将这个模块的文件都移动到新文件夹下，然后保证新文件夹下的文件都是独立的，不引用其他模块头文件。但是很多controller里面可能有几十个头文件引用，我们如果去挨个去检查这个文件的位置，我想这个速度真的是让人无法接受。拆分人员非要疯掉了。
三、我认为的拆分模式
我认为拆分最重要的一步就是把组件独立出去成一个cocoapod包。组件独立出去，才能逐步优化自己组件内的代码。就好比国家建立了，才能逐步发展自己的经济政治。而建立国家的第一步是建立政权，也就是一个模块的文件夹，待时机成熟，再将建立国家，也就是模块的独立。
3.1 建立文件夹
假设我们要对业务My进行组件化拆分，我们在主工程中建立业务My的文件夹，然后将涉及到业务My的代码文件都移动到这个文件夹中去。
例如我们现在的My组件中有以下文件：
图2：
3.2 利用工具进行引用的筛选并处理
这里思想要是引用了上面的模式四，但是如果让我去一个一个文件去找，那我可接受不了，于是iOS组件化拆分工具Nestling应运而生(APPStore传送门->点我跳转)
图3：
我们选中My模块，右键“show in Finder”，将这个文件夹拖入 Nestling 标题栏，Nestling 可以快速检索出该目录以及子目录中的所有h和m文件。如图有12个待处理的文件。
图4：
