从“敏捷”下手

　　“今天，客户的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、注解、继承、接口等，合理利用能够让代码职责单一，模块高内聚低耦合，接口化，可重用，易于测试等等。