@可乐橙_ColaChan ：最近打算在公司内部做一个分享，讲的是组件化的设计与开发的思维方式。准备完演讲资料，发现这完全可以改成一篇文章。藏着掖着不合适，发出来分享给有需求的朋友吧，就当是个试讲了，希望大家帮忙指出错误。
下载地址：https://www.jianguoyun.com/p/DY1Z3bEQwKOaBhimoyg
欢迎关注可乐橙的微信公众号：「可乐橙」
由于本文首先是以keynote的形式诞生的，其中还有动画和视频，所以我比较推荐大家直接下载keynote文件（也存了PPT版本）。内容和本文是一样的，但有些逻辑关系还真得让画面动起来才说得清。提醒一下，keynote文件大小将近150mb，嫌麻烦的朋友，当然也欢迎继续阅读。
组件化
组件化的工作方式信奉独立、完整、自由组合。目标就是尽可能把设计与开发中的元素独立化，使它具备完整的局部功能，通过自由组合来构成整个产品。
对于计算机这么复杂的工业产品，组件化是唯一能使它成为现实的方法。我中学暑假去电脑城打工，跟着别人学习电脑维修。CPU在哪里，负责什么，如何拆装；内存在哪里，负责什么，如何拆装。这些都是基础知识，各部分各司其职，什么坏了就换什么。我还见过资深维修工修主板，他真的能找出主板上哪个电容爆了，换一个相同规格的上去，电脑又能正常开机了。
对产品设计的意义
当然今天我们不讲电脑维修，组件化思维要运用到我们的工作中。首先要了解，它对设计和开发到底有什么意义？
这部分虽然讲的是设计，但对开发同学也有价值。你们能了解设计师在做设计时的思路，说直白点就是摸清楚我们的套路。其实我们做设计的时候会有系统的考虑，并不是天马行空，想一出是一出。
符合功能逻辑
组件化的设计恰恰是符合产品功能逻辑的。特定类型的信息，就有特定的最优展现方式和交互方式，这叫做设计模式。设计模式就应该提取出来作为组件。
比如要从多个维度快速检索和对比大量数据，没有什么能比表格形式效率更高。想象一下，上面这个界面的表格数据，做成卡片式堆叠在一起，划一张换一条，或者像淘宝商品列表那样，一行4列平铺开。那还对比个P啊，用户都要摔鼠标了。
保持交互一致性
交互的一致性，或者说可预测性，是用户体验的根本。比如日期选择组件，在整个产品中就应该只有一种存在形式。如果一会儿是滚轮拨盘，一会儿是日历，一会儿又是下拉列表，这样的设计绝对是不能上线的。
保持视觉风格统一
这部分主要是视觉方面的考虑，更多样式上的差异。不同的样式会给产品带来不同的调性。
就拿按钮来说。圆头造型表现出一种柔和亲切的特质，同时有利于将注意力聚焦到其中内容上。而直角则展现出一种棱角分明的硬朗，边界更加清晰。想一想三星手机和锤子手机的外观造型，两种截然不同的感觉。
为了保持产品视觉风格统一，设计师应该找到最合适的方案，并处处保持统一，不可以太随心所欲。
便于多设计师协作
组件化设计是大型设计项目的必要条件。比如两位设计师协作，一个在设计注册界面，一个在设计修改密码界面，或者在设计某个问卷调查的弹窗。这其中都有表单，两个人设计出来不一样怎么办？一个边框颜色深一点，一个边框颜色浅一点？其实没理由不同，应该保持一致。口头约定太麻烦，而且难以保证执行到位，组件化是最好的解决方式。
便于修改设计
设计总是要修改优化的，有些改动牵扯全局，动静非常大。
比如管理后台的界面，左侧的主导航是全站通用的。某天决定要给它换一套浅色的设计，难道每个PSD都改一遍吗？如果产品逻辑复杂，PSD有上百个呢？
对开发的意义
下面讲讲组件化对开发的意义。其实开发同学从中受益比设计师更多。
降低耦合度
降低耦合度，相信这是大型项目都在追求的。
举个例子，如果要把页面的body区域加宽。内部许多元素因为浮动、固定宽度、百分比宽度、文字行数减少等等，布局会乱套。就像这图里这样，这是因为内部模块的样式对页面父级元素存在依赖和继承。
可能有人会觉得并不存在依赖关系，但其实固定宽度本身就是一种依赖关系。假如说页面主体部分宽度1000px，左侧边栏200px，右侧800px。没错，这是按设计图来做的。那这个800px宽是怎么得出的？正是因为页面主体宽度1000px，才找了个合适的左右比例，设计成这样的。所以无可避免，从设计这个环节开始就产生了依赖关系。
像这种情况，我宁可在模块外面多套一层容器，模块本身的宽度写成100%，外面那层容器属于框架布局，具体宽度写在它上面。虽然DOM树变复杂了，但内外的布局逻辑被分离了。
减少冗余
比方说要新增一个带表格的界面，开发同学按照设计的效果图一行行写页面。但是如果在某个已有界面中就存在表格？或许当时是另一位开发同学做的。相比重新写一遍，把代码要过来直接用更方便一点吧？
如果表格样式之后又要改呢，是不是两个地方都得改。如此一来，用到表格的页面越多，就越容易漏改。而且静态资源服务器上存了太多份关于表格的样式，其中内容明明是一样的。
优化性能
优化性能刚好可以接着上一条说。
那么多份表格的样式，客户端每打开一个新的表格页面，就得加载一次。占用带宽，浪费了缓存资源。虽然一两个的影响几乎感受不到，但这种情况一多，就会对用户体验产生明显的影响。
慢，是用户体验的头等大忌，没有之一。
便于多开发协作
这和设计师协作的道理相同。
如果两个开发同学都在制作带有下拉菜单的页面，这部分工作只要交给其中一人就行了。TA做好之后封装成组件，另一位开发在自己的页面中加载就行了。
便于查错
便于查错，是耦合性降低的一个副产品。它可以大大加快错误排查的速度。
如果页面上出现问题，可以找出每个可能有关的组件，逐个拔除，直到恢复正常。这样就能迅速锁定错误发生的位置。同时组件内也可以形成完整的自测单元，也方便了测试工作。
便于修改
假如设计师每个页面改同一个地方要花一个小时，那开发做同样的事情至少要花一个上午，至少。
封装成组件，可以把这个时间缩短到10分钟。毕竟不用去改几十个页面的HTML、CSS和JS，改一个组件就可以了。
布局原理
讲了组件化的意义，本来顺理成章应该讲组件化的具体做法。但在这之前其实有必要插入这一块内容，帮助没有前端基础的设计师了解，开发是如何把页面搭建起来的。
大家可以先有一个粗略的想象，就像是重力朝上的俄罗斯方块。页面元素都是从下往上这样一行一行搭出来的，不过这个玩家有强迫症