转载

拥抱组件化开发，分享项目内部架构经验

以下情形纯属事实，如有雷同，对号入座吧...

话说大学毕业之后，各奔东西，但由于大学主修专业的原因，还是有很多同学依然在这个行业里面坚挺着，曾经班中唯一的我的女神，也被别人拥在怀里（此时心里一万只草泥马在奔腾，你们可能不明白我心中的痛，是因为你们根本不知道我付出了什么，整整能围绕校园几周的卫生纸啊...），咳咳，跑题了。

言归正传,前几天和一个同学叙旧，都是同行，不自觉的扯到了工作上。他前几个月才进的新公司，小管理，带着几个人搞一个不大不小的项目。我这位同学呢，以前是个安乐主义者（说白了，就是不求上进，如果我这位同学看到了，请放过我...）

在技术这一块说句实话，有点跟不上年代。他跟我聊到了项目的架构这一块。因为我之前的工作一直是架构方面的，所以他跟我聊起了这方面的事。他这个项目思前想后，经过了MPC,MVP,MVVM的反复考量，最终还是选择了MVC，为什么呢？简单，粗暴。

接下来就是分配任务了，用的依然还是传统的单一模块开发。可能说到这里，有人就要问了？难道你们不是单一模块开发？这里我要说下，一般的中小型企业，可能对单一模块开发不怎么排斥，在是在大企业，大项目中，你是用单一模块去开发，估计不是你被开就是你被开，没有之一，所以， 组件化开发是大厂的必备技能。 （划重点）

果不其然，我在听到他说到了单一模块之后，后面的话我都替他想好了，肯定是单一模块团队开发问题多。在开发的过程中，团队开发效率极低，沟通成本大，代码耦合太严重，维护难等等一系类的问题。别问我为什么知道，因为我也遇到过，哈哈...

图一：这是单一模块下的项目结构

从这张图中我们看到了什么？如果你看着感觉问题不大，说明你水平不高（大家先别急着不服，这确实是事实），有的人感觉问题很大，为什么问题大呢？可能会说这样设计，找东西太费劲，不合理。当然，这么说也没错，但是都不是重点。那么该说说我的看法了，在我眼里，千言万语融合成一句话：“耦合太严重”。我看到的不是乱，我看到的是以后维护难，团队开发难，业务扩展难，功能重用难。

举个例子，现在我要把其中的某一个功能迁移到另外的项目中去，按照上图的项目结构，我们要如何迁移。老一套的复制粘贴？那你的复制粘贴就太没有技术含量了。所以，要想迁移，需要把某一块功能对应的业务逻辑也好，资源也好都拷贝过去，最头疼的，还是解耦。所以这些我们所看到的，所说到的，所感觉到的，就是单一模块开发的不足之处。

说了这么多单一模块的不足，接下来，聊聊组件化开发。同样，先上图：

图二：电商项目组件化开发项目结构

以上图二是一个电商项目在组件化形态下的项目结构，用到过组件化开发的同学看到会非常的有亲切感，熟悉的配方，熟悉的味道。

但是有的好，是用眼睛所看不到的，就好比一个人，好与坏，用肉眼是无法识别的，不然世界上哪会有那么多渣男渣女呢（我声明下，我不是渣男，也没有被渣女伤害过，哈哈）。所以，只有亲身体验过，才知道。

这个时候，可能就有人要站出来锤我了，看不到的好，那你说个锤子。大家别急，看我给你们慢慢分析。

首先通过这张结构图我们看到的是一个业务逻辑非常分明的项目，每个业务逻辑的分工也大概能从这粗糙的命名上看到一个大概。其次，我们去分析它之前我们要稍微了解下组件化开发的一些优势：

代码解耦变得明显
功能重用变得容易
团队开发变得简单
编译速度变的更快

那么这些优势是怎么体现出来的呢，首先通过结构我们看到，我们把业务逻辑从传统的单一模块中一个个脱离出来，而且一个个脱离出来的模块都是Appliction类型的（可以单独运行以及测试），把公共层，基础层也抽离了出来（这样我们就可以把所有的第三方API，底层的API都封装在对应的模块中）。

那么跟我们所说的优势怎么挂上钩的呢？当我们业务逻辑分离开来后，其实彼此之间是不会有任何关联的，那么这是不是就是一种解耦？当我们团队开发的过程中，分工就变得更加的明确，彼此之间的沟通交流就会变得很少，每个人或者每个项目小组负责自己的模块不香嘛？（妈妈说再也不用为了别人的代码写的烂而烦恼了

当我们需要把某一个功能进行重用的时候，我只需要把这一块功能所在的模块直接让新项目依赖是不是就方便多了，不需要再一个类一个类的去进行解耦。当我们每次进行编译测试的时候，只需要单独运行我们修改的那部分代码所在的模块就行了，是不是就节约了大量的开发时间呢？（这一点做过项目开发的人都知道，项目越来越大的时候，编译时长也是越来越久）

所以，综上所说，两者一对比，是不是优与劣就一目了然了。