第一次听说“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的依赖注入，指令等。）等，在这之中，有一个最近开始被大家关注，非常重要的设计和管理思想就是“组件化”。

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

我们项目的代码组织结构

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

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

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

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

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

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

medialoot上的一个样例

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

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

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

一个Living Style Guide的样例

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

开发流程

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

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/