创建可维护的设计规范（Living Style Guide）

为什么需要 Style Guide

相信团队工作中，不管是前端还是设计师都有被 “视觉统一问题” 折磨过的美 (dan) 好 (teng) 经历。特别是在中大型、复杂的 web 项目中，很可能存在以下问题（你能对号入座几个呢⊙﹏⊙‖）：

1. 整个项目有上百种不同的颜色。但其中大部分颜色的 16 进制值却非常接近。原因在于，开发甚至设计师使用吸管工具提取颜色值，这很容易照成误差。

2. 不同的开发，对组件的命名可能不一样，比如按钮，有 ‘btn’、有 ‘button’ 等等。加上第一点的问题，造成 css 中诸多长得差不多，但不能复用的代码。

3. 不同的设计师，风格也不相同，同一个表单今天是这个样子，明天它妈都不认识了。而苦逼的开发，要重新还原设计稿。

4. 整个站点的交互，色彩，看上去总是不那么协调。

   显然，如果没有一个设计规范（Style Guide），项目会越来越难以拓展，不可维护。那么制定一个设计规范就很有必要了。

Style Guide 应该是什么样子

一个合格的设计规范，至少需要满足 3 个方面，以下我以 github 的设计规范 Primer 为示例，一个个说：

1. 色彩风格

一个具备美感的网站，并不是色彩越多样越好，我们一般需要定义网站多主色调。
重要的是，定义好色值后，就愉快的可以用 sass 之类的 css 预编译，设置变量了。 (＝^ω^＝)

比如 github 多主色调，是蓝色

2. 组件化

设计规范应该定义出 web 项目常用的组件：比如 按钮、 弹框、表单、侧栏、导航等等。以便复用 (关键是设计时就要复用)。

3. 使用文档

定义好设计风格和各种组件后，要做的就是让各位开发和设计童鞋按规范使用了。 使用文档必须写明色彩具体值、组件的结构、css 命名等，如果有 js 组件，也要写好 js 的 api 文档。

需要自己创建 Style Guide 吗

Style Guide 确实有价值，但也需要一定成本（构建成本、维护成本、推广及学习成本）。那什么情况下需要自己创建 Style Guide？我们可以假设几个场景：

1. 你在一个灵活敏捷的小型创业团队，产品迭代快，变动大。（规范跟不上变化）

2. 你一个人或者就几个人负责一个项目，凡事可以随时当面沟通。（沟通成本小）

3. 你的项目偏向展示性，内容绚丽多样，定制化强。（组件复用性低）

简单来说，如果创建自己的 Style Guide ，成本大于效益，那我们就没必要大费周折搞这些了。
另外，很多时候我们可以直接用 第三方 UI 库 （码农福音 ￣▽￣），它们的文档其实就是一份 Style Guide。而且文档完善，考虑周全，易于学习。比如 Ant Design、Element、Angular Material 等等

到这，你还觉得有必要自己创建一份 Style Guide 的话，请继续往下看。

创建 Living Style Guide

按说设计规范应该由设计师和产品一起定制好视觉稿，前端 原文链接：https://www.f2er.com/javaschema/283490.html