App组件化与业务拆分那些事

最新推荐文章于 2019-10-03 07:59:09 发布

小白爱准准

最新推荐文章于 2019-10-03 07:59:09 发布

阅读量4.4k

点赞数

分类专栏： Android

Android 专栏收录该内容

33 篇文章 0 订阅

订阅专栏

键盘男的博客地址：

http://www.jianshu.com/users/0ef3dc77079c

为什么要组件化、模块化

项目存在问题

代码量大，耦合严重
编译慢，效率低
业务开发分工不明确，开发人员要关心非业务的代码
改代码时，可能会影响其他业务，牵一发动全身

优点

架构更清晰，解耦
加快编译速度
业务分工明确，开发人员仅专注与自己的业务
提高开发效率
组件、业务独立更新版本，可回滚，持续集成

组件化与模块化

组件、模块，中文字面意思相近，在英文上都可以翻译为"Module"，加上Android Studio上，library被称为"Module"，这就不难解释为什么我们谈到“组件化”、“模块化”，两者之间的区别相当的模糊。

组件

App工程上所说的组件，应该翻译为“Component”，意思是组件、部件、元件。在电子电路中，电子元件是电子电路中的基本元素。在App工程上，组件是构成业务或者功能模块的基本单位。原则上，组件与组件之间互不依赖。

例如，图片上传功能，应该叫“图片上传组件”，而不是“图片上传模块”。因为图片上传从功能、业务上，已经不能往下拆了。

图片上传可能使用七牛sdk，或者又拍云sdk。无论图片上传组件用七牛sdk，还是又拍云sdk，都不会影响这个组件的功能，因此组件具有可替换性；同时，图片上传组件可以被多个业务使用，因此组件具有可复用性。由于sdk只是技术细节，它跟业务并没有关系。在业务架构图上，也不会出现“xx sdk”，因此我们说图片上传组件不能拆分了。

同理，日志功能，叫“日志组件”，不叫“日志模块”。

模块

模块翻译为“Module”，字面意思。模块由多个组件构成，它可以实现一个独立的功能，甚至业务。

例如，大众点评的美食功能，是一个业务，可以叫“美食模块”，习惯上叫“美食业务”。它可以拆分更小的模块：搜索、签到、评论等。

两者关系

从上面的阐述可以得出，一个工程，由多个模块组成，每个模块由多个组件构成。但很多时候，两者界限还是相当模糊。例如“日志组件”称为“日志模块”，也没有违和感。

组件从业务角度上不能继续拆分，可替换，可复用；
模块的定义比较笼统，可以是一个Business业务，可以是技术架构中一个业务，也可以是几个组件构成的小功能。

无论是组件化还是模块化，目标都是把臃肿的工程，拆分为更小的部分，解耦各种复杂的逻辑，便于代码管理。

业务划分

一个产品的业务，其实是在规划产品功能，或者做产品原型时，已经定好了（如果连产品或者老板都没这概念的话，我们还是算了）；如果后端牛逼的话，他们也会做业务划分，每个业务部署到独立的容器、虚拟机、服务器。所以，我们做业务划分时，可以咨询后端，也可以咨询产品经理。

例如，大众点评，首页已经展示了好多个业务：美食、电影、酒店、休闲娱乐、外卖、机票/火车票..... 这种多业务APP，通常会把业务尽量展示在首页，这种APP大的业务很好划分。美食、电影这类看起来完全不同的业务，笔者称为Business业务。

但并不是这样划分就OK了，好像大众点评这种超级APP，每个Business业务都能分成很多基础业务。例如，美食业务，可以搜索商铺、预约、使用优惠券、点评、签到等；同时，电影业务也有搜索、优惠券、点评等。所以，搜索商铺、优惠券、点评这种基础业务，可以独立出来，被多个Business业务使用。

组件与业务

上文提过，多个组件构成一个模块，当模块相当于业务时，就是说该业务由多个组件组合而成。

还是拿大众点评做例子，点评基础业务，发布点评需要上传图片、网络提交、记录本地日志等，那么需要调用上传图片组件、网络组件、日志组件等。

不仅仅点评业务调用，所有业务都会调用这些组件。于是，业务架构如下：

Business业务 -> 基础业务 -> 各种组件

业务与业务

情景1

场景：在大众点评订了酒店，入住之后，打开该酒店详情页，大众在“推荐列表”给你推荐若干大保健......

情况1：

前端H（负责酒店业务H）：后端D，麻烦给酒店业务单独做个推荐大保健的api。
后端D（负责大保健业务D）：大保健业务有api D，你调用api D吧

前端在酒店业务Module，写了调用api D，功能上线。

=============================================================
过了一段时间，大保健业务做了调整，数据变动、改域名等。

后端D：前端H，api调整了，麻烦调用api D改为调用api D1。
前端H：现在好忙，我加班搞吧。

于是前端H加班改代码，还要做单元测试等一系列工作。

=============================================================
又过了一段时间，大保健业务再次数据变动。

后端D：前端H，api D1改成api D2。
前端H：怎么又改.....

本来前端H是做酒店业务的，为了大保健的推荐列表，不得不因为大保健业务调整，而加班加点。再延伸一下，如果酒店业务H还需要调用电影院列表、美食列表.....每个业务的改动，前端H就呵呵了。

情景2：

当然了，要前端不改动，后端保持原来api D也可以的。只不过，会引发下面对话：

前端H：后端D，不过你一直提供api D给其他业务使用，当数据调整时，api D做好兼容我们就不用改了。
后端D：你傻逼啊，兼容多麻烦，我们很忙的，你们不就改一点代码吗？我们还要#&^@&#$"@*#......

维护兼容/对外开放接口确实是一种解决方法，只不过会加重后端开发、运维的工作量，长期来看并不科学。

情景3：

如果在前端业务与业务在独立的情况下，也可以相互调用，那就简单多了：

前端H：前端D，麻烦写一个接口，让其他前端业务可以请求大保健推荐列表。
前端D（负责大保健业务D），没问题，你调用D类getHealthCare()，就会请求大保健推荐列表，并返回你要的数据了。

=============================================================
过了段时间，大保健数据变动。前端D在前端大保健业务D做了api D->api D1改动，并对D类getHealthCare()做了数据兼容，前端H不需要额外改代码。

从上面3个情景看，情景3是最优的做法，前端H并不需要跟后端D对接，大保健业务D改动，后端D不需要通知前端H，只需要跟前端D对接即可。而前端的兼容工作，比后端兼容工作要简单得多。