什么是组件化？

如果只是 1 个设计 + 1 个前端之类的配置，很多细节体验问题靠面对面口头沟通也能解决，但如果项目中有多个设计师或多个前端，没有统一的组件规范的话，就容易造成样式混乱、重复设计开发一类的问题。这时推动组件化设计是一件有必要的事情。

我们在设计一个系统的时候会不可避免的与各个不同的角色互动：不同的设计师、不同的前端工程师，这其中不可避免的会出现大量的沟通和协作问题，如何在这类多角色互动中提高效率，降低沟通损耗就不可避免的成为一个问题。「组件化」可以在某些层面帮助我们更好的解决这个问题。在复用和设计过程中，与 Brad Frost 提出的 Atomic Design 有相似之处。

我有着和上面两段话相同的经历，随着项目的逐步壮大，每一次的更新迭代，还是经历着初期4步研发流程（产品→交互→设计→研发）。在这4个环节中，每一次的沟通都耗费了大量的沟通成本。当看到“组件化”标题的时候，感觉这就是我需要的工作方式。（这次没有配图，看起来会干涩一些，找时间我给补上，大家多多包涵。）

通过网络学习，这次组件化学习将整理为三个部分

（一）“组件化”思维

（二）设计的组件化

（三）研发的组件化

一、“组件化”思维

先理解一下控件、组件化的概念

• 控件

是组成应用的最小元素，是一个个不可再被拆分的基本元素，例如：button。

• 组件化

提取产品共用元素，制成通用的元素，有可能是单一控件，有可能由简单控件组成。

• 组件化思维

以实现独立、完整、自由组合的生产方式为目标，尽可能把设计与开发中的元素独立化，使它具备完整的局部功能，通过自由组合来构成整个产品的工作思路。

初识“组件化”

蘑菇街的组件化程序设计火了很久，这个思想早已影响到了设计圈。所以，希望弄明白组件化设计的本质思想，把这种设计思想真实地应用到设计工作流程中，用于解决多角色沟通冗余问题。真正希望实现这个想法，首先得让各个职能的人对“组件化”思想达到共识。

于是，从技术和设计两个角度学习了组件化的概念。技术和设计理解的组件化是不一样的。

二、设计的组件化

设计角度的组件化设计思路

• 目的：

1. 视觉迭代方法基于组件化思路做，有利于让视觉信息展示更系统。减少视觉、研发之间的沟通障碍
2. 加强用户操作行为复用率，有利于降低用户程序性记忆负担。类似的功能，操作一致，更有利于用户记忆操作方式，用户可以更有效率的达到目标。

• 优势：

1 复用：

针对可共用的控件，出一套视觉样式，如满足设定规则，则可用同一控件进行设计。比如: 在sketch里做一套symbols,

2 一致：

设计师聚焦某一元素进行设计时，很难刻意保持与曾设计的元素一致性。这种情况的出现，容易导致用户记忆负担加重。

3 效率：

当设计师有保持设计一致性的意识时，在迭代的设计图中，找出当初那个空间的视觉，是一件不容易的事儿。以组件分类的方式，对各类组件进行迭代记录，有利于视觉、交互风格的统一

4 系统：

组件化的方法让信息传达更系统。在业务→产品→交互→视觉→研发→测试→市场→用户这一系列环节中，信息丢失量降到最低。最终使用户在接收、操作、反馈信息时都更有条理性。不仅提升了产品研发效率，也降低了用户适应各个版本迭代时重复学习的成本。

5 迭代：

当业务需求提出，将原先的地理位置功能进行调整时，设计和研发人员不必逐一查找每个子类，进行迭代。直接提炼出各自的组块，进行升级即可。这样做，提升了工作效率。同时，每一个组件都可以有迭代和设计过程，优化产品体验、行为操作路径、界面风格，都绕不开每个组件的更新，这类整体风格的更替，就是一次设计迭代。

• 挑战：

1 初期梳理设计层的组件，需要紧密的与研发联系；了解一些技术用语和系统设计规范。

2 中期需要根据迭代的进程，不断的优化设计组件

3 后期需要找到迭代周期性规律，对组件进行系统的总结和优化

三、技术的组件化

• 目的：

让整个项目结构层次更清晰

• 实现：

业务模块（子项目）对底层基础模块的依赖，业务间尽可能不出现横向依赖。

• 优势：

1 简化代码整体结构，降低维护成本

2 为贷嘛、模块的复用提供基础

3 提升贷嘛的稳定性（因为对不同业务、模块可以通过仓库权限控制进行物理隔离）

4 提升整体架构的伸缩性，为业务扩展打下基础。

• 挑战：

1 学习成本高

2 团队协作成本高，有可能导致某情况开发效率下降

总结：

技术和设计组件化解决问题的思考方式是一样的，但两类工作具体实现是非常的不一样。但最终，都是为了各自工作中将复杂冗余的碎片，整理存档，便于提升工作效率。

在这里看文章的大部分都是“社稷师们”，所以，不多说社稷师如何理解组件化这个词了。附上研发哥哥对研发组件化的理解，可以进一步对比出社稷师和攻城狮之间理解的不同之处！

• 为什么要组件化？是因为这个项目要庞大到，有很多人很多团队去共同维护，如果按照常规开发模式，会出现高度耦合，比如团队a要用团队b的东西，团队b要用团队c的东西，团队c要用团队a的，互相牵制，这个时候就需要组件化来减小耦合
• 把公用的工具类提出来下沉，然后模块间实现通过中间件来进行业务关联
• 比如，滴滴可能有100个ios，分快车，出租车，专车，巴士，单车，如果不做组件化，大家混一起开发，那么可以收，根本没办法开发，必须把边界划分清楚

对我帮助特别大的几篇文章：

https://www.uisdc.com/component-based-design-and-development

https://www.iamue.com/15813