从“敏捷”下手
“今天，客户的UX又给我邮件了一版新的设计（PDF文件），改动不大，无非就是这个高度再调高点、那个宽度再调小些、这里用粗体、那边用18px的字体，可以参考以前做的手风琴组件的body部分，还有就是，顺便把手机版的样式截个图发过来？”
我：“能告诉我宽度和高度的具体值吗？那个手风琴组件可以在哪个页面找到？”
另一个开发告诉我：”先凭感觉做，然后再找UX面对面的按照要求一个个过。“
我：”好，面对面谈，总比邮件来回要快些。“
UX答复我：”面对面谈可能没有时间，你能先做一个粗略的版本吗？我先看看，然后给你反馈。等你做完所有的部分，我们再约个时间一起过”
即便心里在暗骂（等我做完了，你又跟我说这个不对，那个不对？）嘴上还是说了，“可以。”
然后，我问QA：“有测试环境可以部署我的新代码吗？没有完全做完，但是要给UX看效果。”
QA说：“有，但是部署完估计要1个多小时。”
我看了下时间，再过一个小时，客户UX就下班了，要得到他/她的反馈，估计得明天了！
当我把这个故事讲给别人听的时候，一般会得到两个回复：
- 哎呀，跟我们一样，痛苦的很
- 你们怎么这么不敏捷？
我无法否认这两个说法，很痛苦，也确实不够敏捷。但为我们提供了一点点线索——敏捷。
敏捷宣言中强调：个体和互动高于流程和工具，工作的软件高于详尽的文档。
上面的故事很明显并不满足敏捷的价值观，邮件和截图绝对不可能代表“个体和互动”，一个需要部署一个小时才能看到页面效果的应用也谈不上“可工作的软件”。
怎么破？引入“在线风格指南”
针对当前的痛点，想要破，需要做到至少下面三点：
- 独立前端开发工作，让它与后端逻辑解耦（俗称“前后端分离”）
- 建立“可工作的软件”来展示前端开发结果
- 组件化的设计和开发流程
看到这三点，明白人可能会立刻联想到一个大家耳熟能详的前端开发框架：Bootstrap。没错，它作为一个优秀的前端开发框架，确实满足上面的要求，有许多不错的网站都将Bootstrap作为网站的前端骨架。
Bootstrap有两个特质非常吸引人，优秀的特性和组件和漂亮的开发文档
不过，今天我们不谈Bootstrap框架，我想来聊聊这个漂亮的开发文档，俗称“在线风格指南”。
相信大家对“风格指南”都不陌生，主要分两类：静态风格指南和动态风格指南。
静态风格指南也就是我们常见的静态设计文档，比如，由设计师提供的PSD/PDF等文件，文档中包含：调色板，字体，按钮，链接等等。
（medialoot上的一个样例）
动态风格指南，也称为Living Style Guide（“活的”风格指南或者在线风格指南），它是一个包含风格指南的Web站点，就像Bootstrap开发文档一样。
在这里，我们需要引入的是“在线风格指南”，而不是Bootstrap，这里的不同点在于：
- 角色变化，我们从“风格指南”的使用者，变成了是它的拥有者、开发者和使用者。
- 用户变化，它不再是开发文档，现在用户是UX、前端开发和BA（业务分析），在UX和BA的眼中看到的文档即最新实现结果，在前端开发眼中看到的代码即设计。
- 侧重不同，不仅仅是基础组件，也具有更加偏业务的大型组件。
为什么还要组件化的设计和开发？
组件化的做法在当前的场景下，似乎有点顺其自然，特别是有Bootstrap作为前车之鉴。
我想大家都知道，前端开发其实有一个通病，即大量的JS、CSS和其他资源文件（字体文件、图标、图片），在没有很好的管理控制下，很容易导致资源的冗余，依赖关系复杂度增加、维护性降低、导致之后的开发难度变大。
和后端语言开发不同，比如，Java有包管理和类的支持，有一些常见（或者约定俗成）的实现层次，如：Controller、Service、Repository等；有框架和语言特性带来的优势，比如IOC、AOP、注解、继承、接口等，合理利用能够让代码职责单一，模块高内聚低耦合，接口化，可重用，易于测试等等。
而Web前端开发，由于涉及到的内容较广，又不太可能完全具备后端语言的优秀特性。所以，更加需要开发人员具有优秀的设计和管理思想，比如：CSS的合理命名和管理、有效利用CSS预处理器、JavaScript的模块化、框架的特性（比如AngularJS的依赖注入，指令）、以及组件化等等。
组件化其实是大型软件开发中的一个共识，特别是前端，在没有统一标准的前提下，大家都在不断的造轮子，有无数的人倒了下去，又有无数勇士踩着前者的尸体冲上来。也许是因为它确实能够具有一些非常优秀的特性：单一的职责、资源的高内聚、独立的作用域、可独立的测试、接口的规范化、可重用、可组合等。
我们项目的代码组织结构
从“风格指南”到“驱动开发”
总结一下前面的内容，“前后端分离”，“在线风格指南”，“组件化开发”，似乎我们只说到一些与开发相关的事情，其实不然。
“在线风格指南”被开发，UX、BA共享，合理的组件划分可以合理控制开发闭环，UX可以更快的看到设计实现的原型，提升团队成员沟通频率，BA可以方便的根据组件合理的编写Story（故事卡）。
当这三个角色都参与到这个过程当中时，我们就真正回到今天的正题“风格指南驱动开发”。
这是一个相当新的术语，但不是我发明的，如果要追溯的话，最早在公开场合中谈到这个概念的人应该是Nicole Sullivan，她在2014年9月的一次演讲《Components & SGDD》中提出（Nicole Sullivan目前在NPM这家公司，没错，就是那个NPM，做Product Manager & Design Manager）。
“风格指南驱动开发”尝试着：
- 让UX和前端开发更紧密的工作在一起，将设计与前端开发的工作闭环缩小，更快速的迭代产品原型。
- 将UI开发和业务系统分离开，业务系统不仅仅是指后端系统（不仅仅是前后端分离），也包括业务的Web系统。
- 让设计文档更加“灵活”，更加及时（up to date），更加一致（single source of truth）。
- 让前端资源管理更加规范，开发模式更加清晰。
- 让整个Web开发周期更加敏捷（Agile）。
它是一种前端开发和团队工作方式的实践。
工作流程 – 如何“驱动开发”？
开发流程
怎么样的工作方式，才算“风格指南驱动开发”？其实，当团队拥有了“组件化的思想”和“在线风格指南”，“风格指南驱动开发”的整个过程其实是行云流水的，我简单描述一下：
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，也驱动开发进行更加合理的代码和资源的管理。
