开发 on Victor42

搬砖与拓荒

hi@victor42.work (Victor42) — Sun, 28 Jan 2018 21:17:08 +0000

开发人员们经常自嘲是IT民工、“搬砖”的。在我们外行听来只是自嘲，笑一笑就过去了。不懂他们每天在工作中面对的是什么，我们其实并不理解他们为什么这样自嘲。

最近和同学合作了一个小项目，是个微信H5，其中有数据提交的部分。我负责设计与前端开发，他搞定后端与服务器、域名。在这个项目里略微接触到了一点点后端的东西，对“搬砖”这个话题忽然有种顿悟的感觉，也更进一步理解了开发的难处，这真是一种非常不同于其他工种的工作。考虑到正在阅读这篇文章的你很可能不了解开发，我尽量用大家都能理解的方式来讲这个故事。

这个H5项目的分工方式，是标准的前后端分离。所谓前端与后端，可以理解为事情发生在什么地方，靠近用户就是前，远离用户就是后，中间连接两者的是错综复杂的光纤、Wifi。我负责的前端部分，主要是把页面的外观做出来，展现到用户的手机上，并且处理一些发生在用户手机上的逻辑，例如输入框里填写邮箱要遵循一定格式，没有@符号当然不是邮箱，不能提交。我同学负责的后端部分，就是在网络的另一头接收用户发过去的信息，存到服务器上的数据库里，并做好统计工作。

这里面有一部分工作需要我们共同完成，我们得约定好，我在前端把用户填写的内容以什么样的形式、通过什么方式传输给后端，他在后端接收到这些内容之后要给我怎样的反馈，如果中间出了什么差错，他又会给我什么样的反馈。这就属于开发们天天挂在嘴边的“接口”。

既然合作方式是这样的，双方就有一定程度的相互依赖。我先把前端部分的代码写好了，但是和接口相关的代码要怎么测试？没有后端的配合，我不知道我这些代码写得对不对。这时候同学的后端代码还没写好，我就得等着他。当然，实际工作中，开发人员并不会真的这么傻傻等着，有许多种方式来让其中一方模拟另一方的工作，我们也是这么做的。

他写了一小段代码给我，用的语言是Python，让我在本地模拟这个接口。我一点也不懂Python语言，打开他的代码直接懵B。来来回回仔细看了好几遍，终于理出一点头绪。结合我们之前约定好的接口，大概明白这些代码做了哪几件事情。然后我要做的，就是把我自己的电脑当做一个小型的服务器，把同学的这段代码在我电脑上运行起来，用我的前端代码向这个小服务器提交内容。他的代码自然会给我反馈，让我得以测试自己的代码有没有起作用。

不过事情进展并不顺利，实际上最终是失败了。问题出在运行我同学这段Python代码上。要把这段代码运行起来，有一些前提条件。首先，我的电脑上得有Python这种语言，这个没问题，mac系统自带Python 2.7。然后要安装一些业内广泛使用的代码模块，这些也是用Python写的，同学的代码里用到了这些代码模块。安装其中几个模块时就遇到了问题，电脑报了错误，没有安装成功。

刚开始以为是mac系统的文件夹权限问题，用了许多种方式获得了超级用户权限，没什么作用。各种开发者社区里提供了一些解决方法，升级或重装某些模块，但也没解决我的问题。然后我想会不会是Python版本问题，装了Python 3.6，把mac自带的python2.7换掉了，又重装各种代码模块，电脑给我报了一个语法错误。查资料发现从Python 3开始，有些语法和Python 2不一样，把同学的代码语法稍作修改，语法错误解决了。但最早报的那个错误又来了，继续查资料了解到，我同学用的某个代码模块在Python 3中已经不支持了，需要用另一个模块来代替，这就要对我同学的代码本身进行改造了，彻底超出我能力范围。我也不愿再折腾换回Python 2.7去尝试其他方法了。这条路没走通，最终放弃。

换了一条路，用同学推荐给我的一个现成的工具，也可以模拟后端接收信息和反馈。只是这工具能做的事情有限，不像直接上代码那样神通广大，如果以后有更复杂的需求，也许就不够用了。算了，至少在这个项目中管用，起码问题解决了。

经过这么一番折腾，顿时觉得开发们太不容易了，这种工作和我们做设计的有根本区别。我们用的设计工具、设计方法是不是还算稳定可靠？即使出了问题也基本上能很快解决，重启治百病，再不行重装，我们可以专注于自己的设计工作。对开发人员来说，他们使用的编程语言、代码模块、开发环境就是他们的工具，这些东西出问题的概率比我们的设计工具高多了。有时候是不兼容，有时候是设置不对，有时候是些莫名其妙的问题。这有点像装修工人，一会儿锯条断了，一会儿电钻坏了。狭义地来看，解决这些问题并不属于正常开发工作的一部分，但他们不得不花许多时间来解决。

仔细想一想我熟悉的前端开发，也是这样啊。举个例子，移动端页面里，手指按下按钮时可以加上一个反馈效果，和电脑上鼠标悬停的效果差不多。但是这背后也有一个不明不白的坑，你可以在代码里定义，某个按钮按下时颜色变深，然后你会发现这个代码没起作用，颜色没变。怎么办呢？查一下资料，才知道要加一句代码才能生效，但是这句代码本质上什么也没做。就像下象棋时你抓起马，在棋盘上空挥舞一圈再默默放回原处，你一步也没走。就这样一个神操作却能让手指按下效果生效，这合逻辑吗？不需要合逻辑，你记住这么写就行了。解决这种问题，并不创造任何东西，但这就是开发人员工作中经常要面对的事情。我也相信，多数开发应该不喜欢去解决这种问题，这些事情是苦活累活，真正的创造工作会让他们更有成就感。

深想一层，开发真是一个了不起的职业，不得不为无米之炊。有时候会看到一些技术大V在吐槽，某个最新版开发包又bug百出啦，某个接口挂了又导致产品功能受影响啦。实际工作中，也会听到开发同事被一些与项目无关的技术问题绊住。但是反过来，他们的工作性质很像美国淘金热时期拓荒者，茫茫荒原什么也没有，一批又一批人自己制作工具、盖房子、修铁路。有他们解决种种鸡毛蒜皮与疑难杂症，创造了这些基础设施，后来者才能在前人的基础上建设出城市，创造出繁荣。我们日常工作和生活中，能用上各种稳定可靠的产品，都离不开他们的摸索与折腾。

当然啦，我并不喜欢做这种性质的工作，前端技术也是点到为止，学到能用的程度就行了。对另一个行业胡乱评价了一番，也不知到不到位。不管怎样，心怀敬畏，还是好好做我的设计吧~

组件化设计与开发

hi@victor42.work (Victor42) — Sun, 19 Mar 2017 00:46:29 +0000

终于迎来一期特刊。最近打算在公司内部做一个分享，讲的是组件化的设计与开发的思维方式。准备完演讲资料，发现这完全可以改成一篇文章。藏着掖着不合适，发出来分享给有需求的朋友吧，就当是个试讲了，希望大家帮忙指出错误。

下载地址： https://www.jianguoyun.com/p/Df4KevYQwKOaBhjO8r0EIAA

由于本文首先是以keynote的形式诞生的，其中还有动画和视频，所以我比较推荐大家直接下载keynote文件（也存了PPT版本）。内容和本文是一样的，但有些逻辑关系还真得让画面动起来才说得清。提醒一下，keynote文件大小将近150mb，嫌麻烦的朋友，当然也欢迎继续阅读。

组件化

组件化的工作方式信奉独立、完整、自由组合。目标就是尽可能把设计与开发中的元素独立化，使它具备完整的局部功能，通过自由组合来构成整个产品。

对于计算机这么复杂的工业产品，组件化是唯一能使它成为现实的方法。我中学暑假去电脑城打工，跟着别人学习电脑维修。CPU在哪里，负责什么，如何拆装；内存在哪里，负责什么，如何拆装。这些都是基础知识，各部分各司其职，什么坏了就换什么。我还见过资深维修工修主板，他真的能找出主板上哪个电容爆了，换一个相同规格的上去，电脑又能正常开机了。

对产品设计的意义

当然今天我们不讲电脑维修，组件化思维要运用到我们的工作中。首先要了解，它对设计和开发到底有什么意义？

这部分虽然讲的是设计，但对开发同学也有价值。你们能了解设计师在做设计时的思路，说直白点就是摸清楚我们的套路。其实我们做设计的时候会有系统的考虑，并不是天马行空，想一出是一出。

符合功能逻辑

组件化的设计恰恰是符合产品功能逻辑的。特定类型的信息，就有特定的最优展现方式和交互方式，这叫做设计模式。设计模式就应该提取出来作为组件。

比如要从多个维度快速检索和对比大量数据，没有什么能比表格形式效率更高。想象一下，上面这个界面的表格数据，做成卡片式堆叠在一起，划一张换一条，或者像淘宝商品列表那样，一行4列平铺开。那还对比个P啊，用户都要摔鼠标了。

保持交互一致性

交互的一致性，或者说可预测性，是用户体验的根本。比如日期选择组件，在整个产品中就应该只有一种存在形式。如果一会儿是滚轮拨盘，一会儿是日历，一会儿又是下拉列表，这样的设计绝对是不能上线的。

保持视觉风格统一

这部分主要是视觉方面的考虑，更多样式上的差异。不同的样式会给产品带来不同的调性。

就拿按钮来说。圆头造型表现出一种柔和亲切的特质，同时有利于将注意力聚焦到其中内容上。而直角则展现出一种棱角分明的硬朗，边界更加清晰。想一想三星手机和锤子手机的外观造型，两种截然不同的感觉。

为了保持产品视觉风格统一，设计师应该找到最合适的方案，并处处保持统一，不可以太随心所欲。

便于多设计师协作

组件化设计是大型设计项目的必要条件。比如两位设计师协作，一个在设计注册界面，一个在设计修改密码界面，或者在设计某个问卷调查的弹窗。这其中都有表单，两个人设计出来不一样怎么办？一个边框颜色深一点，一个边框颜色浅一点？其实没理由不同，应该保持一致。口头约定太麻烦，而且难以保证执行到位，组件化是最好的解决方式。

便于修改设计

设计总是要修改优化的，有些改动牵扯全局，动静非常大。

比如管理后台的界面，左侧的主导航是全站通用的。某天决定要给它换一套浅色的设计，难道每个PSD都改一遍吗？如果产品逻辑复杂，PSD有上百个呢？

对开发的意义

下面讲讲组件化对开发的意义。其实开发同学从中受益比设计师更多。

降低耦合度

降低耦合度，相信这是大型项目都在追求的。

举个例子，如果要把页面的body区域加宽。内部许多元素因为浮动、固定宽度、百分比宽度、文字行数减少等等，布局会乱套。就像这图里这样，这是因为内部模块的样式对页面父级元素存在依赖和继承。

可能有人会觉得并不存在依赖关系，但其实固定宽度本身就是一种依赖关系。假如说页面主体部分宽度1000px，左侧边栏200px，右侧800px。没错，这是按设计图来做的。那这个800px宽是怎么得出的？正是因为页面主体宽度1000px，才找了个合适的左右比例，设计成这样的。所以无可避免，从设计这个环节开始就产生了依赖关系。

像这种情况，我宁可在模块外面多套一层容器，模块本身的宽度写成100%，外面那层容器属于框架布局，具体宽度写在它上面。虽然DOM树变复杂了，但内外的布局逻辑被分离了。

减少冗余

比方说要新增一个带表格的界面，开发同学按照设计的效果图一行行写页面。但是如果在某个已有界面中就存在表格？或许当时是另一位开发同学做的。相比重新写一遍，把代码要过来直接用更方便一点吧？

如果表格样式之后又要改呢，是不是两个地方都得改。如此一来，用到表格的页面越多，就越容易漏改。而且静态资源服务器上存了太多份关于表格的样式，其中内容明明是一样的。

优化性能

优化性能刚好可以接着上一条说。

那么多份表格的样式，客户端每打开一个新的表格页面，就得加载一次。占用带宽，浪费了缓存资源。虽然一两个的影响几乎感受不到，但这种情况一多，就会对用户体验产生明显的影响。

慢，是用户体验的头等大忌，没有之一。

便于多开发协作

这和设计师协作的道理相同。

如果两个开发同学都在制作带有下拉菜单的页面，这部分工作只要交给其中一人就行了。TA做好之后封装成组件，另一位开发在自己的页面中加载就行了。

便于查错

便于查错，是耦合性降低的一个副产品。它可以大大加快错误排查的速度。

如果页面上出现问题，可以找出每个可能有关的组件，逐个拔除，直到恢复正常。这样就能迅速锁定错误发生的位置。同时组件内也可以形成完整的自测单元，也方便了测试工作。

便于修改

假如设计师每个页面改同一个地方要花一个小时，那开发做同样的事情至少要花一个上午，至少。

封装成组件，可以把这个时间缩短到10分钟。毕竟不用去改几十个页面的HTML、CSS和JS，改一个组件就可以了。

布局原理

讲了组件化的意义，本来顺理成章应该讲组件化的具体做法。但在这之前其实有必要插入这一块内容，帮助没有前端基础的设计师了解，开发是如何把页面搭建起来的。

大家可以先有一个粗略的想象，就像是重力朝上的俄罗斯方块。页面元素都是从下往上这样一行一行搭出来的，不过这个玩家有强迫症，他一定会从左上角、右上角或者中间位置搭起。当然……搭满一行并不会消除。 ¯\( ツ )/¯

行内元素与块元素

网页布局中有两个概念：行内元素和块元素。它们是非此即彼的关系，网页里只要是你能看见的东西，一定不是行内元素就是块元素。

这两种元素的表现略有不同。虚线框代表一行，但实际上这是不可见的，只是我为了说明布局方式画出来的，其中的绿色矩形才是页面上真实可见的元素。

我们看第一行，这里有3个行内元素。内容长度不同，它们表现出来的宽度就不同，这是一种会随内容变化而改变尺寸的布局单元，而且它们总是从左到右横向排列，只要一行里排得下。

再看第二行，这里只有1个块元素。你看它内容很短，就三个字，却占了一整行。没错，块元素就是这么任性。自习室一卷厕纸占一排座位。

最后看第三行。浅绿色是一个块元素，深绿色是它内部的元素。所以元素之间是可以嵌套的，无论多么复杂的页面，都是这样一层层嵌套形成的。但是要注意，块元素内可以嵌入行内元素和块元素，行内元素只能嵌入行内元素。请看其中的深绿色部分，第二行是一个块元素，设定了宽度，并且居中排列。其实前两个行内元素的右边明明有空间，而且右边还放得下一个行内元素。但即使如此，它还是要占一整行。

当然，块元素这个独占一行的特性有例外，我们接下来就会说。

浮动

刚才讲的是常规的布局方式，我们现在讲两种打破常规的方式。

浮动有两个方向，向左和向右。被加上了浮动属性的元素，表现都会变得类似于行内元素，根据内容变化尺寸。第一行的左右浮动元素都可以是块元素，但它们却排在了一行里。

第二行和第三行是一组对比，表现了非浮动元素与浮动元素混合排列时的规则。第二行的文字是一个常规布局的元素，可以看到左右浮动的元素各就各位，常规布局的文字很灵活地填充空隙，就像报纸排版一样。而第三行里的情况，文字段落也加上左浮动属性，并且限定宽度，它就会跟在左浮动元素的右侧。

当然，如果文字不限定宽度，它还是会独占一行，因为文字足够多。这和块元素独占一行的道理不同，它仍然带有浮动属性，本应该跟在左浮动元素的右边。只是因为自身宽度太大，一行挤不下了。

绝对定位

另一种打破常规的布局方式是绝对定位。这就毫无章法可言了，像狗皮膏药一样想贴哪里贴哪里，还可以像图里这样层叠着贴。总之，绝对定位的元素不会占据常规布局和浮动布局中的任何空间，而是直接挡住它背后的内容。

不过既然可以层叠，就有谁在前谁在后的问题。这和设计工具里的图层是一样的，当然有办法可以控制。

一个页面是如何搭建出来的

http://v.youku.com/v_show/id_XMjY0ODI3OTAyMA==.html

我做了一个动画演示，大家感受一下页面搭建的大致原理。

流式布局

现在要讲的是两个更宏观的概念：流式布局与弹性布局。

我们前面有提到常规布局，那个概念与这两者不能相提并论。其实这两种布局都是基于前面提到的原理实现的，只是区别在于对待自适应问题上采取了不同的策略。

看图中的App store界面，在iPhone 7和7 plus上略有不同。虽然布局形式类似，但7上面只能看到一张banner，而7 plus则能看到左右两边banner露出来。而且App展示区域里，7上能看到3列多一点，7 plus则能看到4列多。屏幕大则视野更大，能显示更多内容，这是流式布局的思想。

弹性布局

弹性布局则是另一种思路。根据屏幕尺寸变化，让界面上所有元素等比例放大缩小。所以无论在什么尺寸的设备上，看到的画面都是一样的，信息容量相同。只是到了大屏幕上，会变得像老年手机那样硕大无比。

这两种自适应方式都有各自的用途，不能说哪种一定更好。但我们在设计时可以考虑一下这个问题，什么类型的设计适合哪种布局。

组件化设计

补完了基础知识，现在就可以讲组件化设计的具体方法了。

提取产品中的共用部分

首先要提取产品中的共用部分。我列举了一些，这些都是极为常见的组件。

这个翻页其实有点问题，少了个当前选中状态，不知道现在是第几页啊。所以说组件的提取要考虑周全，所有可能的状态都要设计。

制作成通用组件

找到了这些共用元素，下面到具体制作环节，关于工具的使用我不会讲太多，主要是思路与观念。我用Sketch录了3段操作演示，我们边看边讲。

Sketch Symbol

http://v.youku.com/v_show/id_XMjY0ODI2MDA0MA==.html

这段视频是讲Sketch中组件的使用。

我们把这个列表项提取为一个组件，现在看其实没什么变化。我们先复制几个出来，让它成为一个列表。然后我们到组件页面去，发现刚才提取的组件就在这里。我们尝试把圆形的头像改成方形，嗯，去掉边框。回到列表界面来，发现整个列表的头像都变成方形了，但我们只在组件里做了一次修改，就达到这样的效果。

Sketch Overrides

http://v.youku.com/v_show/id_XMjY0ODI1ODUyNA==.html

这段视频是讲如何把组件的样式与内容分离开。

还是刚才的组件，不过我把头像右边代表两行文字的矩形换成了真正的文字，我要把它当作通讯录界面来设计。现在我们回到列表界面，发现列表里每一项都变成了姓名+电话号码。然后我们在每一项的Overrides选项中输入数据，因为这是在组件之外输入的信息，它只会影响那一条内容。用这种方式把每个列表项都填上数据。现在我们再进到组件里，做点样式修改，比如把电话号码颜色改成灰色。回到列表，所有电话号码都变灰了，内容保持不变。

这样就实现了样式与内容的分离，降低耦合度对设计同样适用。

Sketch Symbol 的嵌套

http://v.youku.com/v_show/id_XMjY0ODI2Mjc2OA==.html

这段视频是讲组件的嵌套。

组件小的可以只有一个按钮，大的可以是一个交互极其复杂的多步筛选项。所以复杂组件内再嵌入简单组件，这是很常见的事情。

我给刚才的组件又增加了一个按钮，我们把这个按钮也提取成组件，可以看到它出现在了列表项组件的右侧。回到列表界面，每个列表项都有了按钮，我们选中所有列表项，把按钮文字成呼叫。然后右边还有另一个界面，这里也需要一个按钮。我们在此插入之前提取的按钮组件，把按钮文字改为订阅。如此一来，按钮组件就既存在于界面中，也存在于其他组件中。这时候如果想对按钮的样式做点调整，我们再进入按钮组件，改成灰底白字。回到界面中，发现各处按钮都一起变了。

组件化的思想不限于设计工具，虽然Sketch很先进，很利于实现这种工作方式。但PS也有相应的功能，能够以另一种形式实现组件化。

一个组件就是一个完整的产品

设计组件不是把它搬到另一个地方，然后各处集中引用这么简单。开头我们就说过，组件化思维的精髓是独立、完整、自由组合。刚才我们做到了独立，同时也需要做到完整。

就拿按钮来说，我们必须考虑它的各种状态、极端情况、尺寸变化，还有所有附带的交互效果。这才能称之为一个独立完整的组件，满足其他组件对一个按钮的所有要求。除了最标准的默认、按下、禁用状态，还要考虑按钮的尺寸变化，发生服务器交互时每个状态的样式，还有特殊按钮内容的展示效果。

思考相互间的组合方式

组件内部完整了，接下来就是自由组合了。但并不是真的那么自由，我们要确定一些常用的组合方式。

像这样一个后台管理界面：页面的整体背景色，主菜单与右侧内容的距离，输入框之间的距离……这些也都要有章法。

形成规范文档

以上这些工作，沉淀下来，就成了设计规范。这套文档对项目中的其他设计师是莫大的帮助，也是开发人员重要的资料。

组件化设计是一切的源头，如果我们设计部分的组件化工作做得不到位，自己定的规范自己不遵守，开发的同学的组件化工作是无法进行的。

开发组件化

讲完设计组件化，现在我们来讲一下开发的组件化。

按组件，而不是页面来开发

最重要的一点，是需要转变一个观念。我们应该以组件为单位，而不是以页面为单位进行开发。

轻度组件化

组件化开发有两种不同程度的做法。

先讲讲轻度组件化。它的主要思想是使用相同的html结构和特定的class名，并且用同一段css代码定义样式，用同一个js函数来定义交互。

我们来看看上面这个登录框，下面3个代码块是它大致的代码结构。输入框在其他页面肯定也会用到，那么只需要与左边框里的html结构保持一致。各处页面代码中引用同一个css和js文件，至少做到了在一处集中管理样式与交互。但如果组件的html结构发生变化，修改的工作量还是会比较大。

重度组件化

重度组件化的方式可以解决这个问题，不过这就不仅仅停留在思想层面，对项目的代码结构都有一定的要求。

每个组件的html结构、css样式、js交互都独立封装管理，定义好框架和加载方式，内容在加载时从外部填充。

在重度组件化的项目中，每个组件都做到了彻底的独立封装。比如这个页头组件，它的代码存在于独立的目录下，这个目录包含了它的html结构、css样式、js交互、资源图、甚至自测试模块。

那么各处页面中要加载页头组件，往往只是一条语句，将数据传入这个已存在的结构中就行了。

组件如果要与外部进行数据传递，也应该以接口形式对外开放。组件内部是个黑盒，外部只需要了解数据的输入与返回，不必关心组件内的工作原理。

用这种思路管理项目，也会改变开发的协作方式。大家不再是按页面分工，而是按组件来分工。页头和tab由一人负责，列表和页脚由另一个人负责，弱化了相互间的依赖关系。直到将组件拼装成页面，才需要处理组件之间相互作用的部分，但这时候工作量已经被大大消化了。

http://v.youku.com/v_show/id_XMjY0ODI1NzI0MA==.html

我们可以来感受一下组件化管理的项目，应该是个什么样的结构。

一个应用由大量页面组成。一个页面的绝大部分都是组件。组件内部已经定义好了完整的结构，可以独立运行。纵观整个项目，可能就会是这样一个结构。组件的代码占了大多数，能共用的都尽量共用，各个页面的特殊代码则会变得非常轻。各功能模块的划分清晰明确，一目了然。

重在维护

虽然前面说了这么多好处，但组件化不是一件轻松的工作。在项目初期的准备工作会增加一定工作量，但随时间推移会发挥出巨大的优势。

想象一下，像windows操作系统这种航母级的开发项目，如果不用组件化的方式来管理，它有可能成为现实吗？

我们设计师要做的，就是要有专人负责维护设计组件库。组件发生了任何设计修改，或者加入了新组件，都要及时反映在设计规范上。

开发同学也需要指定人员来负责维护具体的组件。他们要做的，我就不好多说了，毕竟我不是专业的。

但可以举个例子，像Google Ara项目的这款模块化手机一样：摄像头模块只负责拍照，处理照片得交给运算模块；而GPS模块只负责定位相关功能，导航语音播报则需要发声模块来处理。任何模块的拆换，对其余模块的运转毫无影响。

双方的维护工作固然重要，更重要的是沟通交换信息。有任何变化都要及时告知对方，组件的高度同步，是这种工作方式得以长期延续的关键。

组件化思维

我们跳出工作的范畴，跳出刚才这些条条框框，单纯想一想组件化这种思想。其实它可以用来理解生活的方方面面。

它的精髓就是这么3点：独立、完整、自由组合。我们生活中见到的绝大多数工业产品，就是这么造出来的，比如汽车工业，比如富士康的iPhone生产线。甚至部队的编制也是遵循这个原理。

而且组件化甚至都不算是人类的发明。即使放在自然界，这也是早已存在的模式。想想我们人体多么复杂，绝对不亚于windows操作系统。但除去极少数器官之外，任何部分损坏或缺失，我们都能活下来。这不得不说是组件化的奇迹。

https://v.qq.com/x/page/e0350h51dga.html

最后，我想给大家看一段1分钟的视频。这是宜家厨房的宣传片，宜家是一家高度推崇组件化的公司。不仅仅是用在生产流程中，也把组件化思维从幕后推向了台前，成为了自己品牌的一种语言。

我们来直观感受一下，让组件化的思想在你脑海中留下一个具象的画面。

部分资料引自《前端工程——基础篇》 https://github.com/fouber/blog/issues/10

在响应式项目中连接设计与开发

hi@victor42.work (Victor42) — Sun, 12 Apr 2015 00:18:00 +0000

[国外设计第82期]

优秀的网页项目，不会单靠好的设计或是开发就能成功——它也需要设计师与开发者的沟通与协作。

我看过相当多的设计师与开发者由于缺乏沟通而糟蹋了项目，结果导致关系恶化。我也见过很多初学的设计师和开发者，通过团队协作创造出惊人的结果。他们避开了潜在陷阱，及时发布项目，并且迅速迭代。这种协作不仅对项目有益——善于沟通协作的团队也是一个更快乐的团队。如果任务并没有如愿进行，也会有更少的误解与紧张。

设计与开发的协作，在响应式网页设计（RWD）项目中尤其重要。各团队如今都要应对大批设备。固定的、“像素精准”的设计，如今该让位于流动的百分比设计。而且，图片资源也需要为多种设备尺寸与分辨率进行优化。

简而言之：响应式设计带来更多变数，需要交付更多资源——这也会导致更多问题。我发现一些技巧，可以克服这些障碍。

1. 首先关注“最极端”的屏幕尺寸

如果对此存疑，可以根据网页的一般经验设定屏幕尺寸范围：iPhone尺寸和桌面浏览器展开。

尽管有些设计师直接“在浏览器中”创作，一开始就完全是流式布局。但多数设计师仍然从固定尺寸开始：选定一组屏幕宽高，以此绘制效果图。

但这提出几个问题：你对开发团队重视到何种程度？应该首先交付哪些高保真资源？由于技术限制需要先考虑哪种设备？

我一直都建议从最“极端”的用户设备入手——最小和最大的设备尺寸。如果对此存疑，我建议以此为2015年的网页用户标准：

320 x 568像素（iPhone 5竖屏）
1600 x 1000px（桌面浏览器展开）

注意：你的用户可能存在差异，所以要看数据分析来定义你的“极端情况”。

“为最小和最大的设备尺寸设计，以此为响应式设计项目的起点。”

先应对最小的屏幕尺寸，这会迫使你做出艰难的选择，选出设计中最重要的功能。大屏幕尺寸则让人从另一个方向思考：最多包含多少内容？文字段落是不是太宽不易阅读？下拉菜单元素需要额外留白吗，如果需要，多少才能避免给人脱节的感觉？最后，选定最小和最大屏幕，通常需要你思考至少两种输入方式——最小的屏幕基于触摸操作，最大屏幕则使用鼠标和键盘操作。

可能最重要的是，当你应对极端情况时，你是在同时处理两种尺寸。并非完全绘制出一种屏幕尺寸，而后去适应另一种。那样会引发设计与开发的冲突。

2. 在各个断点之间讨论内容布局

既然在静止线框图和排版上投入这么多，就千万要记住，响应式网页设计天生是流动的。这意味着众多网站用户体验到的，是你设计的“中间”状态。所以几乎每件设计，都需要考虑特定尺寸间必要的布局调整。比如当尺寸减小时，内容可能会收缩，图片减少为单列。

要避免主观臆断，认为开发团队能够或是应该实现那样的布局调整。尽早行动，先知会你的开发团队，避免他们陷入太深。对于特别复杂的布局变化，最好另外绘制一张线框图或效果图来说明。特殊性不太重要的情况，通过简单的讨论，或者用邮件描述这些变化就足够了。

3. 尽早制定资源图策略

很多响应式图片需要多套资源。我个人网站的主页头图，根据屏幕尺寸和分辨率不同，会从6张不同图片中选择一张呈现。

图片格式与尺寸，通常是设计师与开发者之间的障碍。你可以使用PNG、JPG、图标字体，或者用SVG实现更小的元素或图标。并没有哪个是正确答案：一切都取决于内容和可用的资源。但重要的是对某种格式达成一致，坚持使用它。而且随着网页项目的进行，你还可以创建一些常用图片尺寸。

不过对于如今的响应式设计，这只是刚开始。你要至少输出2套位图资源（JPG）：1套给普通显示器，一套给高分辨率显示器。高级的响应式图片技术，需要更多套资源适应不同屏幕尺寸。

避免到项目末尾再决定响应式图片格式。至少要有一套像素密度显示策略。看看srcset和Picturefill，来保证良好的跨浏览器支持。如果感觉太过了，就从简单入手。用srcset属性来更换一些图片元素，这是个好的开始。看它如何处理，然后由此展开。

4. 微观的思考，模块化的设计

我的响应式设计工作流程深受Brad Frost的Atomic Web Design和Jonathan Snook的SMACSS影响。两者的框架都依赖小型、可复用的组件，以此为基础打造强大的网站结构。

对于交付给开发的资料，我喜欢先专注于小型、可复用的组件。因为它们在不同设备上，通常表现出同样的体验和外观。这样的统一性有利于开发团队消化。另外，小组件通常更容易跨页面复用。所以如果你设计了一套有效的解决方案，之后再重复使用就非常简单了。

小组件通常在不同设备上表现出同样的体验和外观。这样的统一性有利于开发团队消化。

假设你在设计一个注册页面，有标题、大幅图片和表单。根据设备不同，这些元素可能会变换交错或是改变尺寸。起初，要同开发团队一起专注于注册表单的小细节。它看起来是怎样的？需要怎样的验证？相对鼠标键盘，触摸输入会使表单发生什么变化？

5. 从开发者那里获得视觉与用户体验的反馈

有些设计师把开发者阻挡在产品会议、可用性讨论和其他反馈机会之外。只有一个启动仪式，交付一些资源，和一点点其他东西。这是错误的。

要记住，经验丰富的开发者掌握大量知识。如果他们与产品接触了一段时间，他们可能也有独到见解。

前端开发者和设计师的技能通常是重叠的。越来越多的设计师自己写代码。开发者也在刻苦钻研快速原型设计、线框图和美术设计。响应式设计加剧了这项趋势。即使没有“设计师”的头衔，一名开发者也可以表达出强有力的设计见解。

我们得承认，角色与责任的独立仍然有其价值。但稍加融合便可显著改善最终产品。所以，在你的下个可用性测试中，请一位开发者加入来讨论最终产出吧。或者如果你在进行一场设计头脑风暴，或许应该邀请一些开发者。

合作很重要

所有这些技巧都需要规划和认同。由于注重产品发布与截止日期，这就难以做到。但设计与开发关系良好对任何网页项目，尤其响应式设计项目都是有益的。初期的小投资，会为你的团队带来指数级的回报。

原文链接

作者信息： Nick Schaden, Web Platform Lead at Pocket At Pocket, Nick oversees development and design initiatives on Pocket’s web app, Chrome packaged app, and marketing web sites. He has extensive experience introducing and integrating responsive web design, both at Pocket and previously at Animoto, a video startup based in New York. Prior to Pocket and Animoto, Nick worked in technology at Gucci and Goldman Sachs. He loves electronic music and 80s action movies. Follow me on Twitter

设计师写代码的方式

hi@victor42.work (Victor42) — Sun, 09 Nov 2014 12:40:00 +0000

[国外设计第63期]

设计师应该会代码吗？是的，但不是像开发者那样。

这个著名的问题“设计师应该会代码吗？”，答案不只是点个头了，它有更深刻的意义。首先，我们了解一些相关背景。

我们正在迅速地转向移动端主宰的世界。从Sketch 到 Pixate, 再到 Framer，设计师的工具，能越来越简单有效地通过原型表现创意。制作app的成本从没有这么低过。也从从不曾如此迅速。

对于开发者来说，这意味着他们终于可以尽快学会设计。相比学习Photoshop，这一步迈得显然要小得多。他们不会再对绘画、照片处理和3D工具兴趣平平。相反，Sketch的用户界面和OS X很相似，有工具栏、导航和信息窗格。Sketch的UI和Xcode中的Storyboards惊人相似。如果把其他都隐藏，你会发现是一样的，导航在左，内容在中间，信息窗格在右。Xcode甚至有相同的智能参考线和距离功能。相似是件好事。它使你轻松地在工具之间切换。

开发者正在变得更好协作。他们对设计师的期望也是如此。

然后，Swift问世了。或许除了Ruby on Rails，历史上再没有其他哪种语言吸引了设计师们这么多注意。我能自信地这么说，是因为我编写了给设计师的Swift，这个话题和Sketch一样火热，真是难以置信。我的Swift研讨会门票大多卖光了。别搞错了，设计师们其实也想开发app。他们想创造下一个Uber、Airbnb或者YO。他们需要的只是一点点推动力。

正因为我在尝试解决这个问题，我反复问自己，为什么没有更多的设计师学习代码？和我聊过的每个设计师都在寻找下一个原型创作工具。那么，原因很明显，没有足够的为设计师量身定做的资源。Swift book就是一个例子。在里面你学不到如何绘制长方形或是改变颜色。你也学不到如何操控资源图，来让它们完美适应每种设备，比如iPhone 6 Plus。你也学不到如何为界面增添动画。

在讨论解决方法之前，先让我解释一下设计师是如何工作的。

###设计师注重结果

设计师并非不熟悉打字。他们会发tweet、写email，还经常和数字打交道。但和写作不同的是，写代码得不到任何结果，除非你检查语法、调试错误（如果有的话），然后构建app。

类似Swift Playground的东西就是个好解决方法。它还需要做得更好，像PaintCode那样。

###设计师注重UI

设计师每天花费将近8小时移动图形，直到它们合情合理。他们不知疲倦地工作，提供最完美的图片资源，直到开发者满意。不幸的是，有些设计师最后还是遗弃了PSD，然后收工。这些人应该被炒鱿鱼。

完美的工具，应该看起来和他们的设计工具类似。比如Storyboard，有着拖放式界面，可以画图形、测量距离和多设备预览。如果设计师们学过自动布局，他们简直可以包揽一个app所有UI方面的事情，让工程师集中于他们最擅长的领域——实现app功能，消除bug。

###设计师注重动画

和我聊过的很多开发者几乎没接触过动画。要求开发者实现你设计的动画，就像要求设计师写开发文档一样。他们没有受过那方面的系统训练。像Pixate、Framer和Form就是理想选择，因为它们专注于动画，而且它们提供的结果能够被开发者作为代码复制。

###最后的思考

我心里有个毋庸置疑的观点。学习新技能从未如此简单。每周有成千上万新课程、教程和工具被分享。很多人可能会抱怨有太多东西要学。但如果工具再简单一些，难道不就和学习使用筷子一样容易吗？

原文链接

设计师VS开发者

hi@victor42.work (Victor42) — Sun, 27 Oct 2013 14:30:11 +0000

[国外设计第16期]

几乎在每个角落你都会看到有人谈论或自称网页设计师、网页开发者。那具体是指什么呢？

谁是真正的设计师或开发者？可以同时成为这两者吗？

这会是个引来热议的话题，让我们来分解这些术语，挖掘它们的含义和相互间联系

设计师的职责

首先，我们来站在每个职业各自的角度审视这个问题

设计师使用图形和图形设计软件（例如Adobe Photoshop,Illustrator和InDesign）来打造网页的外观。然后将设计稿配合代码来实现

设计师不一定是那个写代码的角色，不过有时也能在团队中独立工作来实现一个网站

多数设计师的工作是运用直觉与想象力输出创意，一般都是典型的右半脑生物。这个领域的人会向多领域发展，不过通常大多都会偏向于图形设计与艺术。设计师会收集设计作品集来向潜在的雇主展示他们的项目作品

最优秀的设计师们对颜色、字体、空间关系、用户与用户体验等多种概念有着深刻的见解

开发者的职责

开发者的职责可以在某些方面和设计师相似，也可以完全不同

一个网页开发者要搭起网站的骨架，往往是从零开始，而且他们懂得网页开发的各种语言。HTML, Javascript, JQuery和CSS都是他们装备。长久以来，开发者并不关注实现某件东西的视觉表现，而是创建一个代码干净整洁、技术可靠的网站

网页开发者通常是左半脑生物。技术实力和逻辑思维是他们能力的重要组成部分。网页开发者可能具有多领域的学历，比如计算机科学或编程。多数雇主在招聘过程中都会要求他们提供作品文件夹

最优秀的开发者往往都注重细节

不同的职业，相同的目标

说到底，网页设计师和网页开发者都是为了一个目标——创建一个吸引用户的网站

为达到这个目标，设计与开发都必须有效而可靠。网站需要美观的界面并且运转良好。颜色和形象要能反映出品牌，界面得激励用户完成你所需的操作

设计师与开发者之间明确的界限已经开始变得模糊，越来越多设计师开始学习代码，更多开发者也开始注重设计理论（这就是为什么设计与开发的文章和教程如此盛行）。可以预见未来这个领域将产生一个新头衔——网页设计/开发

两者协作

关于设计与开发最困难的一件事，是两者协作并找到一种大家都理解的沟通方式。双方都有太多的术语，若不斟酌词句，协作就难以进行

这里有几则小技巧来打破鸿沟：

避免使用术
展示出来，不要光说，让别人明白某件东西看起来应该如何或如何运转。如果不知道怎样解释某件东西，准备一张草图或一个样品来参与讨
集思广益。设计师要接受开发者的设计理念，开发者也要听取设计师在用户体验方面的建
多多学习网站建设中那另一部分工作。钻研你不熟悉的东西，多提问

有可能成为设计师兼开发者吗？

所有的这些区别似乎都意味着设计师与开发者是两个相当不同的职位和角色

但是也不尽然

你也可以同时是设计师与开发者。越来越多人开始这么定位自己，而且这也成为一种非常受欢迎的技能组合。设计师与开发者的角色，正在相当一部分人身上被合并，甚至包括从没考虑过学习开发的设计师，反之亦然

我也是这其中之一。来讲讲我个人的故事：

我以一个平面印刷设计师身份起家。我曾经根本不了解网站如何运转，为何如此，也不曾考虑过创建网站

几年前一切都改变了，我意识到网站可以也应该像印刷品一样漂亮。如果我学习这两项技能，我会成为一个更有价值的员工，也会对自己的工作更加满意

于是我开始学习代码。我不敢说自己非常了解代码。但我所掌握的，已经让自己足够具有竞争力了

我可以和开发者沟通并理解他们的语言。这使我更容易与开发者协同完成项目，但愿开发者会喜欢与能够理解他们的设计师一起工作

现在想想，假如当初我同时学了设计与开发，就像许多职业生涯刚起步的人，会是怎样？

所以，答案必然是肯定的。你可以同时成为设计师与开发者。也许你只擅长其中之一，但始终都应该以全面发展为目标

原文链接