摘要：快速摧毀敵軍設施，殺傷有敵軍生力量，最小化己方傷亡。所以前端工程師在修改完樣式以后，需要反復和設計師還原度的問題。前端工程師依照主題包和設計稿進行前端工程開發。前端工程師很開心，因為不用去投入開發組件庫和調整還原度。

作者: 暮塵

2019年05月11日在上海舉辦 FDCON 2019。筆者有幸受到邀請，參與這次盛會。這篇文章就是演講內容的文字提煉版。

淺談中臺

在開始正文內容之前，先簡單聊聊“中臺”這個詞。 首要要說的是“中臺”這個詞中臺非?；?，從去年下半年到現在，互聯網屆多家知名大公司都公布組織架構調整，紛紛表示要建立各種中臺。 另一方面，“中臺”這個詞暫時還沒有一個很學術很權威的定義。筆者在知網搜索“中臺”，前8頁都沒有看到任何一家商學院或者經管學院發表和“中臺”有關的論文。 所以這里只能基于筆者自己的理解簡單聊聊“中臺”。

以戰爭做一個比喻。上圖是《紅海行動》中的一張劇照。其中黃景瑜飾演的狙擊手和恐怖分子對狙的那場現在還是印象深刻。那么我方狙擊手是怎么樣戰勝恐怖分子的呢");

一線戰斗人員 :“xxx位置發現敵人，請求火力支援。”

指揮部: “收到， 無人機出動”

緊接著，敵軍所在的樓就被炸平了。

這個模式就是上圖所示。一線作戰部隊，靈活且精煉，能夠快速發現敵軍位置。而海軍、空軍等為地面一線戰斗人員提供強大的火力支援?？焖俅輾耻娫O施，殺傷有敵軍生力量，最小化己方傷亡。一線業務方像特種部隊一樣，快速發現市場機會和增長點，獲知競爭對手。而組織內的中臺能都給一線提供強大的技術能力支持，讓他們專注于業務，取得業務結果。

前端能力中臺化萌芽

前端領域呢");

其實隱約有點中臺化的味道。但是現在遍地開花的各種組件庫能夠滿足多變的業務方訴求嗎？答案是否定的。問題的核心點在于業務方對于視覺樣式的多樣性要求。

圖中從左到右，從上到下依次是菜鳥網絡、供應鏈、阿里云、Lazada 在用的業務系統。他們的樣式差異之大，業界現有的任何一套組件庫都不可能同時滿足。

那么在這樣的現狀下，問題的解法有兩種選擇

獨立維護: 視覺樣式和業界各種庫的差異都太大，所以維護一套專屬組件庫

定制現有: 找到業界一個六七成相似的庫，修改它的默認樣式

定制現有這種方式看起來省時省力，可是實際操作起來體驗卻不那么盡如人意。舉兩個例子。

上圖是一個庫提供的樣式修改方式。提供可視化的站點進行修改，體驗很好，動動鼠標就可以把組件庫樣式修改掉。缺點就是只能改顏色。從之前的 4 個業務方系統可以看出，不同業務方的視覺差異并不僅僅是顏色的差異。只能改顏色，業務方是絕對不可能接受。

這是另外一個庫提供的樣式定制的方式。它對外暴露了許多的變量， 通過修改webpack.config.js 的 sass-loader/less-loader 配置進行。這種修改方式的問題在于組件樣式修改的工作落在了前端身上，而樣式的最終決定權在業務方設計師手上。所以前端工程師在修改完樣式以后，需要反復和設計師Review還原度的問題。反反復復幾個來回往往就是這么個結果。

所以獨立維護和定制現有各有優缺點，并沒有任何一方出現壓倒性優勢。最后就出現內部組件庫遍地開花，技術棧林立，技術沉淀難以復用。

當時其實在中臺思想的指導下，有些組件庫的開發者就嘗試把組件能力進一步透出，使得“定制現有“這條路更好走，讓業務方不用把開發資源投入到基礎組件庫的開發上來。 這個最初的想法就是Fusion Design 起點。

Fusion Design 成長歷程 Fusion Next & 樣式配置平臺

為了解決多業務多樣式的問題，我們自己獨立維護了一套組件庫 Fusion Next。然后為這套組件庫打造了一個配置平臺。二者結合就是一個組件庫工廠，可以生產出各種樣式的組件庫。 具體效果如視頻所示:

由于掘金不能播放視頻,故把視頻鏈接放在這: alifd.alicdn.com/assets/fdco…

實現Fusion Next & 樣式配置平臺的核心技術點有三個。

變量抽取

規則實現

動態渲染 接下來一一講述。

變量抽取

變量抽取就是決定一個組件哪些量是可以配置，那些量不可以配置，可以配置的量抽離出來。這部分是Fusion Design開發過程中投入人力最大的一個點。 變量抽取的新核心理論是原子設計理論。

原子設計理論認為頁面應該是可以組合和分解的。按照原子設計理論， Fusion Design團隊匯總了業界組件庫包含的各種組件，然后再把復雜組件(原子設計中的組件)拆分成簡單組件(原子設計中的元件)的組合，進而拆分成為基礎變量(原子設計中的元素)。

一個簡單的Button就可以拆分成茫茫多的變量。而正是這么多的變量財能夠滿足業務方多變的視覺樣式要求。最終50+組件梳理出3500+可配置量。

規則實現

上文中梳理出的3500+變量及其組件的配置規則。得益于前端領域成熟的 CSS預處理語言，這些變量和規則可以容易的落地為SASS/LESS變量。雖然這是一個很重要的技術點，但是難度并不大。這里不細說了，具體見Fusion Next Github

動態渲染

剛剛如果看了視頻的同學可以看到，當組件的配置項的值被修改了以后，頁面上組件狀態也是跟著動態變化。其核心的一點就是服務端SASS編譯。

當用戶修改了某個變量，被修改的配置項會數據會被發送到服務端。

在服務端編譯成為可用的 CSS，再返回到瀏覽器。

瀏覽器收到CSS數據之后，找到承載樣式的style標簽。

把其中的內容替換為剛獲取的CSS。

就達到了動態渲染的效果。但是這個方案是 3 年前確定方案。隨著瀏覽器原生能力的增強。CSS Variable 特性已經具有的較好的兼容性。CSS Variable 配合 一個存在許久API calc() 可以達到一樣的效果。而且省去通信時間和服務器編譯時間。這個方案是配置平臺未來的演進方向。

主題包

配置平臺的數據日常是沉淀在數據庫中，為了方便前端工程師在開發中使用。用戶完成配置以后， 配置平臺會發布一個主題包，他是一個合法的npm包。包內既有元數據的沉淀: SASS/LESS/Javascript，方便SASS/LESS/CSS in JS 體系使用;也提供生產可用的CSS文件。

工作流

在完成配置平臺之后，前端工程師也設計師協作的工作流程如下圖所示。設計師在配置平臺修改組件樣式，產出主題包。前端工程師依照主題包和設計稿進行前端工程開發。

FusionCool的誕生

新的問題

在完成Fusion Next + 配置平臺體系之后，逐漸開始接入實際的項目中使用。前端工程師很開心，因為不用去投入開發組件庫和調整還原度。可是業務方的設計師用的不開心了。憑空增加他們的工作量卻沒有幫他們提效。

下圖是設計領域很受歡迎的軟件 Sketch。左邊是默認樣式的設計素材，一般由組件開發團隊對外提供。右邊是修改過樣式后的組件。雖然在配置平臺可以很方便的調整組件樣式?？墒窃赟ketch中，設計師要把左邊樣式的 Button 調整為橙色圓角 Button ，至少需要3個步驟。一個組件都已經如此麻煩。Fusion Next 內置50+組件。設計師的工作量之大可想而知。

FusionCool

上述問題的核心在于，設計素材并沒有根據配置平臺的數據而修改自身樣式的。使得設計師在配置平臺修改完樣式還要到Sketch中再做一遍相同的工作。所以 Fusion 團隊又開發一款Sketch插件。

由于掘金不能播放視頻,故把視頻鏈接放在這: alifd.alicdn.com/assets/fdco…

FusionCool 1.0

在接到FusionCool的需求時，最自然的想法就是 基于Fusion Next庫，直接把 DOM節點轉換為圖片文件。設計軟件對于圖片文件是有天然的親和性。而且DOM節點截圖技術已經十分成熟。

這個想法很快遭到了否決， 主要是因為兩條理由

圖片文件生成后編輯其中的內容比較困難

jpg/png 放大失真

圖片文件里面有一種比較特殊格式文件——SVG。SVG 和 HTML 都是類XML語言，轉換方便。純文本格式方便編輯。所以基于這條技術路線完成了 FusionCool 1.0。最終還原度大概在95%。對于業務方，特別是有像素眼的設計師，是不能接受這樣”低“的還原度。所以這里就不贅述技術細節。

FusionCool 2.0

95%的還原度不能接受，但是至少比沒有好。一邊 FusionCool 1.0 踉踉蹌蹌的運行， 將就著使用。另一邊 Fusion 團隊在尋找新的技術方案。然后愛彼迎開源的一個庫 React Sketch.app。這個庫最初的目的是期望設計師能夠通過寫簡單的React代碼管理Sketch中的設計系統。在知乎上也有熱烈的討論如何評價 Airbnb 發布的 React Sketch.app 工具？。

這個庫最初的夢想，我們這里暫時不去深究。最關鍵的一點是 React Sketch.app 指明了一條道路: React 代碼可以直接渲染到 Sketch 中。經過評估，基于現有的Fusion Next再維護一套可渲染到Sketch的組件庫成本并不是特別大。所以我們基于Fusion Next開發了一套庫Sketch Next。目前我們正在做的工作是兩件事:

Fusion Next和Sketch Next兩個庫做代碼融合， 使得一個庫就可以同時渲染到瀏覽器和Sketch兩個端。

組件規范沉淀，使得業務方自己開發的組件也可以活動相同的能力。

在 React Sketch.app 技術的加持下，Fusion Next做到了99.9%的還原度。

無障礙

現在有了組件庫， 也有了Sketch 插件，Fusion Design就能夠做到”設計前端兩開花，藝術工程雙提效“。 然而，過了不久業務方又找過來了說: 業務收到了律師函警告，求援助。我心里犯嘀咕: 你們難道在站點上放人家唱、跳、Rap、打籃球的視頻了");

相關法律

對于網頁無障礙，各個國家和地區都有相應的法律法規做出要求。如果網站沒做無障礙適配工作，是有法律風險。

為了解決業務方無障礙法律風險，Fusion團隊從組件庫底層開始接入無障礙能力。 并且在這個基礎上做了3件事情。

能力內置

全球范圍內， Web無障礙最權威的技術指導是W3C組織發布的 WCAG。目前 WCAG最新的版本是2.1。 Fusion Next根據 WCAG 2.1的指導，內置無障礙適配。 下圖中左邊是Fusion Next Select 組件，右邊是Select組件渲染出來的HTML，可以看到HTMl標簽上多了一些不常見的”aria-“標簽。這些標簽都是根據WCAG的要求生成，方便讀屏軟件識別其中內容。

WCAG并不只是對于代碼層面有要求，對于網頁的設計也是有要求。FusionDesign在設計方面完成了適配工作。

舉個例子: 視障人群并不是完全看不見， 具體見盲人的世界到底是一片黑色，還是連黑色也不存在？。多數其實能看到色彩，只是模模糊糊。所以對于網頁的色彩，hover態、disable態的顏色就要和普通狀態的顏色對比度差異夠大，才能便于視障用戶感知他們的區別。所以配置平臺在修改品牌色的面板中，增加了顏色對比度標識，方便設計師更好的選擇顏色。

權威合作

Fusion 團隊還和無障礙領域的權威研究機構————浙江大學中國殘疾人信息和無障礙技術研究中心(后文簡稱浙大無障礙中心)進行了深度合作。 浙大無障礙中心權威在哪里呢");

產出指引

WCAG 2.1是最權威的指導，但是他更像是一個需求列表，前端工程師直接去閱讀，還是有一些理解成本和實踐成本。Fusion團隊基于自己的理解和實踐， 編撰并對外發布《Fusion Web無障礙開發指引》。這份開發指引，針對前端工程師編寫，更容易理解和上手。

中臺初長成

在經過業務方的接入增多，業務復雜性增加。Fusion Desgin也在不斷豐富自身的能力，中臺自身能力強大了，才能給業務提供強有力的火力支援。

目前內部服務 40+ 業務方， 2000+項目。

去年12月，Fusion Design對外開源開放。目前對外版FusionCool日活1500+，發布7600+主題包。

未來探索 橫向拓展

橫向拓展，即從服務設計師和前端的協同，擴展到其他協作領域。

縱向深入————設計稿生成代碼

在設計師和前端的協同領域深挖， 目前設計稿轉代碼都是通過AI去”猜測“設計稿上某個組件是那種組件，它對應的代碼是什么。但是如果設計師是通過FusionCool輔助創作設計稿，那么FusionCool是可以知道設計稿上的組件是對應的那個組件以及其對應的代碼。 那么在AI+FusionCool兩條腿都走路的情況下，期望能夠在設計稿生成代碼領域做出新的突破。

一分鐘廣告 官網 & Github倉庫

官網: fusion.design Github: github.com/alibaba-fus…

釘釘群二維碼