1. 前言
三国演义里开篇就说: 天下大势, 分久必合, 合久必分. 我发现这话套在软件开发上, 也特别贴切. 我记得我刚入门时做 java 后台开发, 以及后来做 Android 应用程序开发, 刚开始都是采用中心化管理的思想, 将相同的资源集中进行管理, 但是做着做着, 发现集中管理的资源太多了, 多人开发时牵一发而动全身, 进而又要对原本的项目进行拆分, 演变出什么 SOA 架构, 什么微服务, 以及我这里要讲的 Android 组件化实践.
现在已经有了很多关于组件化开发的文章了, 组件化原理很简单, 但是真正实施起来还是挺困难的. 在最近这两年的时间内, 我曾经主导开发过多个采用组件化架构的 App 项目, 其中有对老项目进行重构的, 也有一开始就采用组件化架构的新项目, 在这期间踩了不少坑, 也积累了不少经验, 现计划将这些都记录下来, 对或者不对欢迎大家一起探讨.
2. 单一工程开发模式遇到哪些痛点
为了便于区分, 在这里我将开发模式分为 2 种: 一种是项目组件化开发, 一种是单一工程开发模式.
单一工程开发模式
顾名思义, 就是一个代码工程 (Project) 对应一个 App 了, 这个 App 的所有业务功能都是集中在同一个工程里实现的.
组件化开发
简单来说, 就是将一个 App 的业务功能进行拆分, 每一个功能都是一个单独的工程, 每个工程都能独立运行, 且只包含自己的业务, 我们姑且叫这个独立的功能为一个组件服务, 最后整个 App 由多个拆分出的组件集成而成.
已经有很多文章对什么是组件化有更详细的介绍了, 我这里就不赘述了. 在讲组件化开发的好处之前, 我先以我的亲身经历来讲讲单一工程开发模式的痛点有哪些.
对工程的任意修改调试都要编译整个工程, 效率十分低下;
做 App 开发时, 我们需要经常在手机或模拟器上进行调试, 而每次调试都需要对整个工程进行编译, 然后安装在手机上运行. 即便你只是改了一句代码, 或是 UI 调整了一个像素点, 同样需要完整的编译工程. 当工程代码越来越多时, 编译也会越来越慢, 你可以想象一下我修改了某句代码, 编译一下需要等待 4,5 分钟才能成功运行的场景么, 那简直让人崩溃, 严重影响了开发效率(想起曾经用 eclipse 开发 Android 时, 各种转菊花, 卡顿得让人想死的心都有).
不利于多人团队协同开发;
早期一个 App 可能就 1,2 个人来开发, 但是随着业务的扩张, 我们可能会发展到一个团队来开发一个 App, 少则 4,5 个人, 多则 10 几个人甚至更多. 像手机淘宝, 微信, 支付宝这些巨无霸 App, 他们的 App 开发人员估计起码有数百个.
以 10 人团队为例, 如果 10 个人都是基于同一个工程的代码拉分支进行开发, 每人的开发任务虽然不同, 但是都能修改整个工程的任意地方. 为了适应自己的需求, 团队内某人改了某句代码, 但是这个改动又有可能影响别人的开发, 这样开发人员之间势必要花更多的时间去沟通和协调, 没法专注自己的功能点. 最后进行 10 个人的代码合并时, 有过这方面经历的人, 就知道这是一件多么痛苦的事情, 解决冲突解决得你要怀疑人生.
无法做到功能复用
我曾经做过一个项目, 每个开通这个业务的城市, 都要做一个单独的 App, 初期我们只开通了 3,4 个城市, 需要同时发布 3,4 个 App, 这些 App 大概 6,70% 功能是相同的, 但是都需要加入地方定制功能. 如果你每个 App 都采用单一工程模式开发, 刚开始你可能每个工程都有同样的代码存在, 只需要复制拷贝一下就行, 但是如果有需求要对这些进行修改时, 你必须得每个工程都逐一修改一遍, 然后每个 App 都测试一遍, 工作量直接翻了数倍.
业务模块间耦合严重
采用单一工程模式开发项目, 到最后势必会造成业务模块高度耦合, 可以说是你中有我, 我中有你, 修改任何业务都有可能导致牵一发而动全身, 这显然是不利于后期项目功能维护以及迭代开发的.
3. 为什么要进行组件化开发
前面都是我在单一工程开发模式下碰到的问题, 已经严重影响了我们团队的开发效率以及质量, 所以我才极力推崇组件化开发方式. 它解决了我上面的所有痛点:
极大提高工程编译速度
进行组件化拆分后, 每个业务或者功能都是一个单独的工程, 这个单独的工程可以独立编译运行, 拆分后的工程通常都比较小, 代码量也比较少, 我再也不用像以前编译一下得等待好几分钟了.
业务模块解耦, 有利于多人团队协作开发
业务组件之间不能相互引用, 每个组件都把对应的业务功能收敛在一个工程里, 彼此互不打扰. 在多人团队里, 每个人只负责自己的业务模块, 他对业务功能的增删改查, 都只限定在自己的这个业务模块里, 不会影响其他人的业务, 他代码质量的好坏也只会影响到自己的业务模块; 对测试来说, 也十分方便, 大部分情况下, 我们只需要着重测试修改过的业务组件即可, 而不用老是进行全部回归测试.
组件化是功能重用的基石
业务组件类似一个个积木一样, 我们可以用积木搭建出不同的房子, 同理我们也可以创建多个不同的 App. 我们只需要维护好每个组件, 需要用到该组件的功能时, 一建引用集成就可以了.
当然, 组件化并不是说只有好处没有坏处, 例如:
组件化开发前期可能要花费更多的时间来进行模块拆分;
一个人的小项目完全没必要组件化开发, 那样只会给自己带来更多的工作量;
组件化可能会带来更多重复的代码;
组件化需要良好的架构设计, 包括怎么拆分业务, 组件之间怎么通信等等, 需要有个高水平的架构师统筹全局, 经验不足的同学盲目进行组件化反而会适得其反, 带来更多的麻烦;
4. 小结
本文描述了单一工程开发与组件化开发的优缺点, 这些都是在实际工作过程中的一些感悟. 需要注意的是, 我们并不要为了组件化而组件化, 我们要根据实际情况来决定. 如果组件化带来的好处远大于单一工程开发, 那你就大胆使用组件化开发方案吧.
来源: http://www.jianshu.com/p/d0f5cf304fa4