组件化开发浅识

原创 2018-08-09

  本篇文章谈的不是具体怎么去研发去实现，先仅从一个整体认识去从浅析一下组件化，谈一谈个人对于它的认识。分析一件事物、事情是否合理是否有必要去做，个人喜欢5W2H分析法，在当前角度此篇对于组件化仅从2W1H：What、Why、How也就是下图中的右侧部分谈一谈个人认识。

What 是什么？

组件化开发个人认为是一种为了解决复杂业务逻辑的开发思想。组件化最初是由后端为了解决后端的复杂多变的功能性而提出来的，但是随着前端功能、业务也越来越复杂这种思想在前端也开始盛行起来。

组件化开发有何特点？

• 既独立又统一

每一个组件都可以作为独立存在，可以在业务逻辑上随意替换和删除，对整体不会造成太大的影响；但单个组件不能够满足整体业务需求，又需要按照一定规则将他们统一起来形成一个项目

• 分拆封装

任何一种开发思想、开发架构都是建立在业务逻辑的基础之上的，抛开了业务单独谈思想、框架都是无意义。组件化就是根据实际业务的情况按照某种粒度进行分拆，然后按照业务逻辑进行封装组合

• 组件具备可移植性

UI、业务、基础每个层面上的组件都是具有可拔插性的，甚至可以通过一定控制实现插件化，满足不同功能需求、不同运营、不同销售需求的场景

它的目的是什么？

• 解决多人多团队协作难

团队分工协作的价值在于最大程度地发挥每一个人的能力，但往往多人跨团队协作不仅存在沟通上的难题，也存在于开发过程中与后期维护，组件化思想可以帮助我们去尽可能做到：谁开发，谁负责；谁管理，谁维护；职责清晰，沟通简单方便

• 实现项目代码的高内聚低耦合

组件内部完成业务要求的独立子功能，功能单一职责明确；对外又能够仅提供联系最少最简单的接口

Why 为什么？

了解清楚了什么是组件化，它有什么特点，目的是什么，接下来谈一下为什么在项目中需要用到组件化。

前面已经提及到组件化是一种思想，那么一种思想就不会仅仅作用于技术开发这一环节，产品、设计、运营、甚至说技术支持也是可以运用的，由于对运营与技术支持接触不多，这里仅从技术、产品、设计浅谈一下个人观点与体会：

组件化开发之于研发、测试

• 提高开发效率和后期维护，更加有利于开MVP（最小可运行版本）迭代
• 添加修改组件时候只要保证对外接口不改变就无需担心影响其他组件，也无需对关联调用组件进行重新测试，减少测试工作量
• 可单独开发、测试、发布一个组件，不需要开发完某个功能
• 提高编译、自测效率。因项目复杂，整个编译环节可能会比开发所占用时间更多
• 某个组件出现问题，可直接对组件进行处理，不必担心会因为修改而影响到整个工程
• 组件之间调用标准化。组件只需要提供一种服务能力或者接口，由中间件调用或发现服务
• 更适合快速迭代。组件划分后，可多个组件按照某种协议并行开发，无需等待、担心某个组件是否提供了所需服务，加快开发进度
• 组件可以提供很好的提升代码的可重用性，可随时引用或删除
• 更好更快速排查问题，某个组件出现问题，相关负责人直接对组件进行处理
• 方便拔插、方便集成、方便删除、方便删除后重新加入
• 减少项目中的僵尸代码，往往开发过程多人接手，或需求多次变更后会遗留很多不会再重用代码
• 业务划分更佳清晰，新人接手更佳容易，可以按组件分配开发任务
• 如果有新人的加入，可以直接分配组件进行开发、测试，而非需要熟悉整个项目，可以从一个组件的开发使新进人员比较快速熟悉项目、了解到开发规范

组件化开发之于设计

对于设计而言，包含两个重要方面的内容，一是UI设计，二是UE设计，如果能够将组件化用于设计上：

• UI主题风格统一

在项目、页面复杂度逐渐增加的过程中，UI在设计时难免存在相关细节疏忽，可能会存在颜色略微偏差、icon重复定义、尺寸发生改变、布局不统一等情况，组件化可以通过统一的组件调用将整个应用UI风格尽最大可能保持统一。

• 有助于制作标准主题库

每个组件迭代过程中，业务包含简单，更能够清晰所使用的UI颜色、icon等元素，有助于组件与master主题、颜色、icon等抽离出来做成自己的标准主题库，不仅可以在研发角度开发出主题库，也可将内部的所有元素制定自有标准（如: 阿里iconfont）。

• 保证多端多人合作规范

这个约束不仅对于制作主题库来说重要，更是在多端（如Android、iOS、前端H5）多人协作开发时有帮助，可以避免出现各平台开发人员各自按照自己理解命名，多人多端合作时通过标准库直接查找到主题搭配，而非从代码中查找甚至说从所给的标注中重新生成，也可以改善后期人员接手上也造成的麻烦，也在一定程度上减少加入的资源，减小发布包的大小。

• 约束UE体验

组件分离开来，使得项目整体感受落实于每个模块、每个页面上，对于UE在事件响应、页面跳转、动画、整体感受等方面的体验是有约束力的。

• 保持交互一致性

可复用组件可以在整个项目中仅存在一种形式，能够更好的保证交互上的一致性

组件化开发之于产品

• 仅谈一点

长期以来，或多或少会存在这样一个误解，以为做程序开发只要能够了解如何去实现某个功能即可，亦或甚至只需要头部开发者明白怎么去做即可。一个出色产品的出现必定要经过：跟随、比肩、引领三个阶段，作为设计、开发、测试人员在一二阶段占有重要作用，或许产品设计人员能够有组件化思想，将其产品需求设计的每个模块拆分为我们做什么？为什么做？重要性是什么？怎么做？...... 说服执行者，亦或是说你的客户（很多时候开发人员做出来的产品自己会很少用，这可能也是其中缘由之一），会对整个产品的实现质量、效率上有所帮助。个人认为：如若团队中的每个人能明确动机与目的，转而由态度所产生的行为更能够带来一个较好的结果。

How 怎么做？

简单介绍一下组件化对于研发的架构构想，如下图，整个构想会分上下两部分：

• 上线路，完成组件团队内、跨团队开发

• 下线路，提供给第三方开发者或公司使用

可能会存在这么一个场景：部分公司有自己的研发能力，需要我们提供的大部分功能，但其自有的一些较为机密数据不能够交由他人开发。亦或者说为了满足定制化客户的需求，需要什么购买什么。

• [组件]

分为三层：基础层、业务层、表现层。基础层为自定的基础组件，在这其中包含我们需要的网络、数据存储、三方库引用、UI基础组件、组件中间件等；业务组件涉及到所需要完成的某个需求，这里是根据公司业务需求进按照某个粒度就行封装实现；表现层可以理解为对于业务层中的业务组件再次封装的模块。

• [私有/公有仓库]：

组件开发完成后将其推送至对应的仓库即可。对于不同的平台使用不同的包管理工具：iOS可使用CocoaPod Android/Java开发可使用Maven、Reactive/RN/JS等可使用npm，这些管理工具都可以提供很好的对公对私组件、模块、项目的管理。

• [Web后台管理]：

上面架构图的Web管理后台其实可以不存在，但是为什么这里需要考虑进组件开发框架中呢？原因有三：

其一：一个复杂的项目需要组件间相互调用，相互通信，可能会需要一个短链配置管理；
其二：我相信你们如果是作为一个平台，那么可能会遇到过很多需要定制化业务需求，或者你在出售你自己业务的时候需要分别为不同用户定制不同的App，而不是把你所开发的所有业务组件一起打包送你给你的客户，这个时候你就需要用到后台管理来根据不同用户，不同权限，不同选择构建你的移动应用；
其三：管理合作方的的组件配置问题

• [Jenkins]：

是持续集成的一个很好引擎，可很好的帮助我们对单个组件、单个某块、整个工程的构建、自动化测试、签名、部署、发版等工作。

• [SDK/Framework]：

通过一定规范提供给合作部门、合作第三方使用。

• [第三方开发]：

只需要按照开发规范进行开即可，开发完成后的业务组件有两种方式快速接入到平台：一种是可以将你的业务组件直接上传提交至我们的仓库管理，同时在我们的后台按照规范提交你的组件模块；另一种方式是可能不希望让别人看到你的代码，但是又不想自己搭建一套自动化打包、部署Pipline，那么可以提交到你自己的私有仓库打包成Framework并且创建好你的Private，告诉平台你的仓库地址即可。

  以上是个人在组件化开发的一些整体理解，如若需要切实的进行还是需要一段较长的路需要去走、去探索：这其中涉及产品、设计、研发、测试等，最主要还是研发这环节。也并不是所有的项目组件化都适合，至少它不适合小团队、不适合小项目、不适合短期投入的产品...。

  当然组件化也并不是没有缺点，任何事物的存在都是多面性的。在保有优点的同时，也存在诸多缺点，这就需要使用者去判断、去平衡：在何种时机采用何种方式花费多大的代价达到何种预期的结果。