建立可維護的設計規範（Living Style Guide）

建立可維護的設計規範（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

按說設計規範應該由設計師和產品一塊兒定製好視覺稿，前端?們再根據視覺稿書寫規範。因此在這，我先略過視覺稿，直接來講如何建立一分靈活可維護的設計規範（Living Style Guide）。

咱們須要 node 環境 , 以及 kss 這個工具。kss 能夠根據 css 裏面的註釋，生成 Style Guide 的文檔。

簡單說下用法：
第一步，先安裝 kss

npm installl -g kss

第二步，建立一個文件夾，而後下載 kss 的 demo。

mkdir kss-demo
cd kss-demo
git init 
git clone https://github.com/kss-node/kss-node.git

安裝依賴

npm install

而後打開 demo 文件夾，咱們能夠看到以下結構，kss 就是根據裏面的配置內容，生成 Style Guide

demo 
     - components // 定義組件
        - buttons.hbs   // 編寫 html 示例結構
        - buttons.less  // 編寫組件樣式
     - forms   // 定義組件 
     - homepage.md  // 文檔規範內容 支持 markdown
     - kss-config.json  // 配置文件
     - kss-headings.less    // 規範文檔的樣式
     - mixins   // less 方法
     - preview.png
     - styles.css  
     - styles.less

咱們能夠用 demo 來改動下，文件夾更名爲 my-style-guide (隨意) 作成咱們本身想要的內容，而後

kss --source my-style-guide

kss 工具就會幫你建立一個styleguide文件夾。裏面是 Style Guide 的內容了。配置跟生成出來的內容，關係以下（簡單畫畫圖，詳細內容，請下載研究）。

less(固然 css 和 sass 也能夠) 裏面的：

1. 註釋 => 編譯成文檔說明

2. less 的樣式 => 組件的樣式（button 等）

3. hbs 文件裏的內容 => 組件的結構 (使用了 handlebars 模板引擎)

這麼一來，簡單的 Living Style Guide 就建立好啦（鼓掌）。
另外 github 上也複雜些的 kss 相關模板。
kss-node-template、 kss-node-template-such-as-github

不過真正項目裏，應該如何定義色彩、風格之類的呢。這就要找設計師啦。哈哈哈。

在嘗試性使用 kss 的過程當中，我的感受有些不足之處，或者說麻煩之處。
好比 kss 生成的文檔說明，所有寫在 css 裏，而且要遵循 kss 的語法，而在 css 裏寫 Markdown ，也蛋疼。這增長了學習和編輯的成本。
kss 中 Style Guide 的組件結構，須要寫在另外一個文件，還用了模板引擎，這樣維護起來不方便。
在和團隊童鞋探討以後，咱們決定放棄使用 kss，不過他提出了個簡單版思路，有興趣的童鞋能夠嘗試下：

大部分的文檔內容用 md 來編寫，組件的結構寫在該 md 文檔的 code 裏，css 則跟 md 文檔同名， 這樣，工具就能夠根據文件名爲索引，生成對應的 html 文件，再組織這些生成的文件，拼成完整 Style Guide。
好比：

• components // 定義組件
  |----buttons.md // 編寫 html 示例結構，和文檔
  |----buttons.css // 編寫組件樣式

這樣，寫起來舒服，維護起來也舒服些。若是你們有更好的思路方案，歡迎拍磚探討！

週末大放送：
最後，給設計師童鞋們推薦個能夠根據設計稿，從 Sketch 生成 Style Guide 的插件。同樣牛逼烘烘！

Craft 簡介

Craft 是一套面向 Sketch 和 Photoshop 的插件組，幫助你簡化設計流程中的自動化填充，提高工做流效率，將注意力集中在設計自己。做爲一個工具套件，Craft 包含下列工具：

• 批量複製：快速複製重複圖層，並方便調節間距、數量等。

• 樣式庫：在 Sketch 中生成一個 StyleGuide。它使一個新的頁面有不一樣的調色板，字體，文本樣式和自定義元素，您能夠創建本身。與你的團隊分享和同步整個庫。

• 智能圖庫：支持 Dropbox，unsplash，本地文件夾，或 Web 頁面上調取圖片到 Sketch 畫板中。

• 數據：帶來真正的文本，圖像，JSON 等內容到你的 Sketch，無需花費時間進行模擬數據。

其中的樣式庫功能，就能夠方便的生成 Style Guide:

另外這款插件毫不是一個內容生成器那麼簡單。它能夠幫助你擺脫「Lorem Ipsum」，使用真實的產品數據進行設計，這對設計師來講簡直過重要了！具體的操做辦法能夠去他們的 官網 看視頻教程。