背景
随着业务不断的发展，组织结构的调整，对于垂直化业务划分的团队来说，App的解耦需求变得越来越迫切。
举个栗子🌰来说：通过垂直化业务划分后，一个团队负责“首页”+“搜索”+“产品详情“；另一个团队负责“我的”；
这两个团队分别负责不同的代码，没有交叉的代码，端开发同学对号入座，原则上不会产生交叉资源。
这与之前普通的开发方式的区别是，之前端开发同学们相当于一个池子，有需求过来，这个版本需要做哪些东西，大家打散了平均匀给所有同学，按照计划进行开发。
而现在池子变成了两个，两个池子相互不通，并且每个池子已有固定的部分代码需要对应，不会需要越池。从代码上是可以将一个App的代码割裂成两份，两个池子的同学各自开发自己负责的代码，最终发版的时候合并即可。
代码分离
为什么要分离成两部分代码？原因是对iOS在10人左右团队中，新老同学同时在进行开发，冗余代码加上一次次业务代码、技术代码迭代，代码数量总体是只增不减，慢慢的就会发现，整个工程的代码依赖极为复杂，而且编译速度奇慢。
慢到什么程度呢？让人感到沮丧，对脑中已经构思好的代码，瞬间被这种沮丧冲乱，编译构建的时候不得不跑去干一些别的什么事情，最后终于可以验证的时候发现前面的思路早就乱了。
所以分离代码虽然会有一部分成本，但如果能预期看到这样的沮丧会减少，也是感觉值得的。
多端共享代码
如果只是一个App，两个开发团队来维护，操作上分离成两份其实是最突出性价比的做法。
但如果一个App里的功能模块还要被复用另一个App中，比如产品详情，有对于维护买卖家两个App的团队，可能就需要共用这部分代码。
这时就非常有必要将原本分离成两部分的代码中的一部分，再次做代码分离，以便满足代码可以被复用，且足够解耦。
方法
上面说了这么多，核心其实就是分离代码，分离代码的方式方法有很多，最直接的就是使用Cocoapods来对代码进行解耦分离，但这里有个大坑，后面会详细介绍到，这个坑让分离的代码意义和价值变少，也会介绍如何规避和改进。
同时也会介绍有哪些方式方法可以优化和改善，以达到理想的方案。
