從“敏捷”下手
“今天，客戶的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，也驅動開發進行更加合理的程式碼和資源的管理。