NO END FOR LEARNING

Writing blog if you feel tired | 学海无涯 苦写博客

你听说过“风格指南驱动开发”吗?

| Comments

第一次听说“SGDD”

我听说过TDD(测试驱动开发),我在软件开发中一致坚持执行

它以其倡导先写测试程序,然后编码实现其功能得名,在开发中,我们带着两顶帽子思考:先戴上实现功能的帽子,在测试的辅助下,快速实现其功能;再戴上重构的帽子,在测试的保护下,通过去除冗余的代码,提高代码质量。

我也听说过BDD(行为驱动开发),我熟练使用Cucumber编写端到端测试

它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间进行协作,通过用自然语言书写非程序员可读的测试用例,以扩展测试驱动的开发方法。

我头一次听说SGDD(风格指南驱动开发),我蒙蔽了

我打开百度(请不要鄙视我,它毕竟还是“最好的中文搜索引擎”),搜索关键字 - “风格指南驱动开发”,却只看到寥寥的一篇翻译“干货”。收货不多,但能证明了一点,即风格指南驱动开发(SGDD)的思想还没有像TDD和BDD那样在国内得到较为广泛的推广。

本文是一篇我目前所在项目实践的总结,也是对这种新的开发思想的思考。

“风格指南驱动开发”是什么?

“风格指南驱动开发”其实是一个相当新的术语,最早在公开场合中谈到这个概念的人应该是Nicole Sullivan,她在2014年9月一次演讲《Components & SGDD》中提出SGDD的概念(Nicole Sullivan目前在NPM这家公司,没错,就是那个NPM,做Product Manager & Design Manager)。

“风格指南驱动开发”尝试着:

1.让UX和前端开发更紧密的工作在一起,将设计与前端开发的工作闭环缩小,更快速的迭代产品原型
2.将UI开发和业务系统分离开,业务系统不仅仅是指后端系统(不仅仅是前后端分离),也包括业务的Web系统
3.让设计文档更加“灵活”,更加及时(up to date),更加一致(single source of truth)
4.让前端资源管理更加规范,开发模式更加清晰
5.让整个Web开发周期更加敏捷(Agile)

它是一种前端开发和团队工作方式的实践。

而实践的方式,就是做到以下两点:组件化的设计和动态风格指南。

组件化的设计 - 我的眼里一切都可以是组件

大型的Web应用通常都会有大量的JS,CSS和其他资源文件(字体文件,图标,图片),随着页面越来越多,交互越来越复杂,如果没有很好的管理,就会导致资源的冗余,依赖关系复杂度增加,可维护性降低,开发难度增加,这其实是前端开发常见的通病。

如果和后端的开发相比较,比如:Java开发,天生就拥有包管理和类的支持,而根据业务/功能层次来划分,我们拥有了常见的(或者约定俗成)实现层次,如:Controller,Service,Repository,Util,Constant等,同时,我们还会利用框架和语言特性带来的优势,比如,IOC,AOP,注解,继承,接口等,而统统这些能够带来的好处就是职责的单一,模块的高内聚,接口化,可重用,易于测试等等。

对于Web前端开发,由于涉及到的内容较广,又不太可能完全具备后端语言的优秀特性,所以,更加需要开发人员具有优秀的设计和管理的思想,比如:CSS的合理命名,有效的利用CSS预处理器,JavaScript的模块化,利用框架的特性(比如AngularJS的依赖注入,指令等。)等,在这之中,有一个最近开始被大家关注,非常重要的设计和管理思想就是“组件化”。

组件是一个个独立存在的模块,它能够具备一些非常优秀的特性:单一的职责,资源的高内聚,独立的作用域,可独立的测试,接口的规范化,可重用,可组合等。这些优秀的特性其实就已经非常接近我们常常在后端语言中描述的特性。

Alt text

我们项目的代码组织结构

除开开发关注的特性,组件化对于整个软件开发流程也是有益的,合理的组件划分可以合理控制开发闭环,UX可以更快的看到设计实现的原型,提升团队成员沟通频率,BA(业务分析人员)可以方便的根据组件合理的编写Story(故事卡)和Task(比故事更小的任务卡)等等。

而这些让组件化成为“风格指南驱动开发”的必要元素。

“风格指南驱动开发”中的“风格指南”

除了组件化,“风格指南驱动开发”还需要另外一个实现驱动开发的基石,也就是它名字中的“风格指南”。

“风格指南”对大家应该不陌生,主要分为两种类型:静态风格指南和动态风格指南。

静态风格指南是我们比较常见的静态设计文档,比如,由设计师提供的PSD/PDF等文件,文档中包含:调色板,字体,按钮,链接等等。

Alt text

medialoot上的一个样例

动态风格指南,也称为Living Style Guide(“活的”风格指南),它是一个包含风格指南的Web站点。当你看到它时,也许你会觉的有点像BootStrap,然而,和BootStrap以及静态风格指南不同,企业开发中的Living Style Guide得到的是:

1.设计在代码实现层面上的最新版本,它包含了展示UI组件交互和行为的Demo以及相应的实现和使用代码等
2.用户是UX,前端开发和BA(业务分析),在UX和BA的眼中看到的文档即最新实现结果,而在前端开发眼中看到的代码即设计
3.文档中看到的实现即是产品实现中最终的一致结果
4.除了基础组件,也具有更加偏重业务的大型组件
5.产生供产品环境使用的最终资源(库)

综合以上不同之处,相信大家可以猜到对于“风格指南驱动开发”来说,它所需要的是后者。

Alt text

一个Living Style Guide的样例

工作流程 - 如何“驱动开发”?

Alt text

开发流程

也许,你会更加关心“风格指南驱动开发”的整个开发流程,但其实,当你拥有了组件化的思想和“动态的风格指南”,“风格指南驱动开发”的整个过程其实是行云流水的,我简单描述一下:

1.挖掘到新的需求/特性

当新的需求出现时,UX开始进行页面设计,Living Style Guide会作为设计的参考文档,通常情况,设计师会查看已有的调色板,字体,和其他基本元素或组件来组成新的页面布局。在组件化的思想和Living Style Guide的帮助下,BA和设计师都会尝试使用或者扩展现有的组件。

2.抽象成组件

一旦设计完成,BA,UX和开发会开始讨论如何把新的设计细分为独立的组件,哪些是已经存在可以重用的,哪些是新的需用新建或者扩展实现的。Living Style Guide作为桥梁帮助设计与开发进行沟通,促进双方的理解,确保实现的准确性。而抽象出来的组件,帮助BA划分任务和故事(Story),以便更加准确的估算“故事点”。

3.实现和文档化

此时,Living Style Guide是作为一个开发框架和设计试验场(playground)。

作为一个试验场(playground),允许你随时看到每一个开发出来的组件,作为开发框架,允许你快速开发,它和真正的产品实现完全隔离,这种隔离会鼓励你一以更加抽象的方式创建组件,以便于让他们更容易被重用。

Living Style Guide的开发注重组件化的隔离和规范化的开发流程(套路清晰明了),我们常常会开发一些自动化的构建任务来帮助快速初始化一个组件需要的基本内容,只要开发人员对开发所需的前端技术栈有掌握,就能较快速的开发完成相应的组件。

而开发完成的组件在Living Style Guide中立刻变成“活的文档”,可以快速展示各种不同的组件应用场景,提供给UX和BA做审查(review)。

4.组件在产品应用中的热插拔

最后一步,就是将组件应用到真正的产品实现中(该产品代码应该是与Living Style Guide毫无关系的业务代码)。而对于Living Style Guide输出的结果,应该可以任意选择刚好满足需求所需要的组件,拥有足够的灵活性,才能实现它在产品应用代码中的热插拔。

如果还有第5步的话,那就是重复上面的4步,这就是“风格指南驱动开发”的完整流程。

留在最后的思考 - 它到底驱动了什么?

作为好奇宝宝的你们和我,当你读完这篇文章,当我写完这篇项目上的实践总结,其实,应该仍然在思考,它到底驱动了什么?

在TDD和BDD中,通过测试,驱动我们编写刚好满足测试和满足需求的实现,而测试反过来成为保护伞,在我们通过重构提升代码质量的同时,保证功能的安全性。

那么,“风格指南驱动开发”到底驱动了什么?也许,它驱动着我们尽最大可能去重新使用已有的组件(代码)和设计更通用的组件,也驱动着我们(开发,UX,BA)进行更加频繁的沟通,它驱动着BA(业务分析)书写更加合理的Story,也驱动开发进行更加合理的代码和资源的管理。

如果转载本文,请注明转载地址: http://benweizhu.github.io/blog/2016/11/19/style-guide-driven-development/

Living Style Guide - 缩小设计和开发的沟通鸿沟

| Comments

本文作者:朱本威,杨松

什么是Style Guide(风格指南)?

如果你做过Web开发,我打赌你肯定听说过“风格指南”!

风格指南是什么?它是一系列关于书写和设计标准的文档,比如一些常见的标准有:字体,颜色,Logo,间距等等。

风格指南最早出自于印刷行业,比如:出版社就是风格指南的常见用户。

Alt text Alt text

从1999年到2016年,《读者》的封面风格都没有改变过

好的品牌,通常都有一个非常棒的风格指南,无论是哪个行业,比如:KFC。我们也将KFC的这种风格指南成为VI(Visual Identity,企业视觉设计)。

Alt text

KFC老爷爷大家都认识

对于我们的WEB开发,也需要风格指南,目的是保证最终的交付产物和最初设计的一致性,打造出一致的核心用户体验。

Alt text

Optus澳大利亚电讯公司

风格指南过去的工作方式

在过去,一种常用的工作方式,设计与开发是分离开了。设计师在这儿,前端工程师在那儿,中间有一条无形的巨大的鸿沟。

唯一的沟通渠道就是这样一个PDF材料。设计师最开始把PDF给你,然后和工程师各自为阵开始忙自己的,打死不相往来。

沟通不及时就不说了,有时候设计还要埋怨你,说你的实现怎么和他最初的设计不一样。

每一个工程师都应该都会有一段被设计师逼着改实现的经历,也许有的设计师们根本不理解我们修复IE问题时的痛苦,也不一定明白PDF文档沟通的效率是有限的。

“我怎么能知道点击每一个按钮时候的行为呢?”

答案是我根本不知道,等我看完了一百页文档,还不如你直接给我解释来得简单直接。

Alt text

UX,UI Dev和Backend Dev

而每一次修改都需要很长的反馈周期,中间浪费了不少时间。

然而,当第二版,第三版,第四版来的时候,我的PDF和PSD文件已经堆积成山,我也不清楚哪一个才是最新的版本,没有版本管理工具,即便有,这种二进制文件也很难立刻查看它和上一个版本的区别在哪。

而且我相信大部分像我一样没有强迫症的人,一定是文件下载或者拷贝随意放置在桌面或者什么位置,然后常常根据时间排序去找最新的。久而久之,就不知道在哪了,然后又找设计师要一版。

经历了以上种种的痛点之后,我们是怎么做的?

Living Style Guide

Alt text

我们忍受不了这种不够敏捷的工作方式,尝试着用新的方式去解决这个问题,我们构建一个Living Style Guide。它是一个在线站点,同时也是一种工作方式,一种实践。我们尝试通过这种实践去解决这个问题。

Living Style Guide和Style Guide的区别:

一个直观的变化就是,曾经的PDF文档,代码化了。比如,最开始只存在于PDF文件中的调色板,字体,在网站上就可以直接查看,而不用担心是否过期,找不到等等。

同时,也是一种工作方式的改变,我们的设计师与工程师需要更加紧密地工作在一起了。让Living Style Guide成了一个钮带,连接着设计师与工程师。

设计看到的文档即代码,开发人员看到的代码即文档。不会出现设计师所认为的设计和实际开发出来的结果不一致的情况,我们做到Single source of truth(唯一真实来源)。同时,你看到的是动态,可交互的一系列组件。不需要考虑怎么用文档去描述一种行为,你所看到的就包含自身行为。

敏捷宣言中有这样一句话:工作的软件 高于 详尽的文档,Living Style Guide在努力实现这一点,尝试将设计与前端的闭环缩小。

聊聊工程师们关心的干货

选择合适的技术栈

技术栈的选择还是要回归到项目需求上。我们从大的方向上考虑了这么几点:组件化,数据驱动,易定制和可测试。

Living Style Guide是一个供设计师和前端开发工程师使用的平台,并可以将开发的内容打包使用在其他不同的Web应用平台,对通用性和易用性都有较高的要求,我们没有做一个大而全的框架,而是想要做到以组件为单位,灵活发布,并能灵活使用在各种平台。

Alt text

我们的技术栈

上面这张图涵盖了我们大部分的技术栈内容,具体内容我就不单独介绍了。不过,我突然想起来前段时间有一篇非常火的文章《在2016年学JavaScript是一种什么样的体验?》,它写的就是我们这个feel。

关于代码组织结构方式

组件化是我们的核心价值,所以在代码结构上,我们将“自包含”属性作为一个很重要的特性。每一个组件包含了它自己所需要的相关文件:测试文件(单元测试,功能测试),样式文件(Sass),组件和文档,而公共的部分,我们抽离到其他位置,从而尽量做到高内聚,低耦合,同时提高代码重用性。

Alt text

我们项目的代码组织结构

需要注意的点

组件化的好处是相互隔离,又可被重用。实现组件化一定要需要合理的分类和管理好组件,比如,区分业务组件和通用组件,保证被重用的组件拥有足够的可扩展性。

最后

Living Style Guide是我们在缩小设计与开发沟通鸿沟的一种尝试,努力将闭环缩小,以提高效率,降低成本,这是一种实践,也是设计师和工程师工作方式的改变。

转载请注明: http://benweizhu.github.io/blog/2016/10/27/living-style-guide/

参考资料:
1. https://asinthecity.com/2011/11/10/the-difference-between-a-ux-designer-and-ui-developer/
2. 敏捷宣言( http://agilemanifesto.org/iso/zhchs/