我以前工作过公司有一个项目，需要我将不同项目(以下简称原项目)的代码切割出来一部分，再将切出来的部分组成一个新的项目(以下简称组合项目)，而且要求我当原项目有更新的时候，需要将更新后的代码合并进这个组合的项目中来。刚开始考虑很简单，把项目中的代码一遍一遍的拷贝过来就好了，很容易啊，可是慢慢的我应付不来了，代码量太大，每次拷贝的时候我都需要将新增的代码通读一遍，找到其中需要的部分拷贝到组合项目中来，于是我的团队就在想能不能通过将代码模块化的思路来解决这个问题。
第一步，在原项目中构建模块，先将原项目中需要的代码进行整理，把在组合项目中需要用到的代码都整合到一个目录下(当然目录下还是可以有子目录的)，这样每次拷贝代码我只需要将这个目录下的代码拷贝到组合项目中，这样就可以节省大量的时间了，
第二步，有个问题出现了，新拷贝进来的代码还是还是需要花费时间来找到入口，一旦原项目中的功能入口变了，组合项目中也需要变更，于是在原项目中添加了一个类用于处理真个功能的对外和对内的交流工作。
以上两步已经将我的工作量减少了90%，后来由于一些原因我离开了那个公司，但是这次的代码经验让我对于项目的架构有了一些新的想法，我们能不能将项目的业务进行分离，将模块进行分离，清晰业务边界，清晰功能边界，粗略的画一个架构图，
基础：包括通用控件，通用方法，常量都可以放在基础中，
模块：包括网络模块，图片处理，分享，支付等等，模块和模块之间不进行相互调用
业务：根据具体的业务来做出划分，业务掉用模块，业务和业务之间不进行相互调用
APP：使用业务，通过业务的的对外类来调度使用业务
这样一来，我们可以根据需要针对某一模块，某一业务进行扩展，只要保证负责出入口的类一直，在模块内部或者业务内部代码的有变更的时候，也不会对整体有非常大的影响。
