立足
三年前剛開始做 Sketch 生成代碼插件時，定位的就是原型工具，不是可用頁面。我當時認為直接由設計稿生成可用代碼是走不通的，原因有兩個:
- 當時的前端自己都還處在爭論用什么框架的時期，得先解決了這個問題設計工具才可能生成被大部分開發者接受的代碼。
- 設計語言與編程語言差異比想象中的大。
關于第二點這里詳細說明一下。設計稿中的圖層通常表達的是離人眼前后順序，前面的覆蓋后面。而圖層的分組也只是為了管理而已，沒有邏輯上的聚合關系。如下圖，背景的紅色圖層與形狀圖層是平級的，沒有展示出包含關系。
并且在設計中常常會按類型而不是按邏輯歸屬把一些東西放在同一圖層，這樣設計師在修改的時候比較容易批量操作。而在前端的組件化中，組件幾乎一定是按邏輯功能劃分的。而組件的層級表達也是邏輯上的包含關系。這種關系只有一部分能和視覺上的從前到后匹配。以 React 為例，很多組件層級的表達就不是前后關系。
因此，想要實現視覺上到邏輯上的完美轉化，只有兩種可能，一是按邏輯的要求約束視覺上的圖層、分組使用。二是靠機器學習之類的方式去智能識別(社區已有開源項目)。
第一種方式其實技術上可行，但是不人性。兩個方面，一是給設計師造成了巨大的學習成本。這個巨大指的不是設計師學不會，而是指規則有可能因為開發者設計得不完善或者不夠簡便，使得設計師要做很多他自己無意義的額外操作。例如本來設計師一個圖層可以畫完的元素，在規則的要求下要進行分組分層。二是這些規則很可能忽視了設計師的需求，例如之前所提到的同一圖層管理同一類元素的的問題。我有嘗試使用社區內的一些方案，從設計師的角度來說，那種體驗就像：
第二種方式當時雖然有想過，但是沒有深入去探索，原因也是當時的前端變化太快，我認為找不到足夠穩定的樣本能去訓練。
有了以上結論后，我想到了雖然直接生成可用頁面不行，但是生成原型還是有可能的。設計師和前端的溝通成本也是一個需要解決的問題。最常見的就是設計師需要告訴前端某個元素 hover 上去是什么效果，點擊是什么效果等。這些東西既然設計師已經畫出來了，那么能不能把這個表達的方式自動化掉，省去人工溝通的成本。像 Axure 之類的原型工具就有類似的功能。只是這些工具一般都定位給產品做最初的原型設計，缺少了視覺上的細節，不能完全取代設計師和前端的溝通。
因此我開始做從視覺稿到原型的 Sketch 插件 Blade。這個插件雖然也在一定程度上要求設計師按某種規則來設計，但是這種規則對設計師已經是有意義的了，能省去他的口頭描述。
旁觀
在開發完第一版后，由于工作的調動就沒再維護了。后來更是由于 Sketch 升級后的 api 變化導致不能用了。讓我比較意外的是這兩年間持續不斷地有人開 issue，寫 email 希望我繼續更新。我在 issue 中委婉的表示項目已經不再維護，大家可以試試社區的其他方案。但社區的其他方案屈指可數，并且方向和定位其實也都不太相同。
按我所接觸的順序一一介紹一下。
Marketch，也是生成 html 文件，但是專注于標注功能，方便前端同學取位置和樣式信息。這個定位非常精確，讓前端不再需要自己裝 Sketch。
從 Sketch 的生態體系看來其實插件可以分成兩大類，一類是用來方便設計師的操作的，例如快速生成一些常用的元素，如頭像、地圖等。另一類就是擴展設計之外功能，例如生成標準、原型。對個人開發者來說開發前一類的插件難度比較小，而且收益很明確。而后者相對來說難度和收益就都不樂觀了。在后來我再看到的第二類插件中，幾乎都是團隊進行開發的。例如 Framer 和 Proto.io。
這兩個工具的共同點是都已經脫離了 Sketch 體系，變成了獨立應用。以導入的方式來整合 Sketch/Photoshop 等工具的產出物。但定位也仍然是可交互的原型產品。直到 Launchpad 出現，才算得上我知道的第一個定位于生成可用頁面的 plugin。
從 Lauchpad 所提供的功能看來，生成頁面功能非常簡單，只有簡單的鏈接、表單，還不涉及到復雜的交互邏輯。生成的代碼也不能二次開發。但是 Launchpad 做成了一門生意，并且好像運營得還不錯。從跟我進行郵件溝通的設計師中，我也發現了不少想要直接建站的需求。再回過來看我之前認為這條路不能成功的兩個原因，反思一下是我想錯了嗎？
第一個原因是我認為生成的代碼必須要前端能接受才行。Launchpad 沒有提供二次開發這個能力，似乎就回避掉了這個問題。但同時也就限制了能力。
第二個原因是設計語言和編程語言的差異。同樣的，縮小了需要覆蓋的場景，不提供二次開發，也使得對設計師造成的負擔最小化。
這樣看來不是對錯的問題，而是本來定位就不一樣。我在思考這個問題的時候其實并沒有區分場景，定位的是從簡單頁面到復雜的單頁應用應該都能適用的情況。Launchpad 提供了一個新思路，就是縮小場景后能實現一部分。
前面列舉的相關的插件都是從設計的角度出發制作的。而不久前 Airbnb 的 react-sketch 插件則提供了一個新的角度。
它的目標是設計資產的管理。它的能力是將組件這種設計資產從代碼導入到 Sketch，同時也能從 Sketch 導出到代碼。所以即可以說站在了設計師的角度也可以說是站在了前端的角度。在知乎上有一個評價 react-sketch 的問題。前兩個回答非常的透徹。讀者可以看一看。回答里提到的這種工具在真實團隊的適用并不樂觀，我有同感。因為它站在了一個新的角度看問題，那么必須也得有一個站在同一角度的新角色(設計工程師?)出現才能顯示出它的價值。否則單獨對設計師、對前端，都會感覺意義不大。
同樣，react-sketch 也提供了一個新思路，就是以設計資產這個維度來實現代碼和設計元素的統一是有一定價值的。這種統一，其實也就是能互相轉換。
投石
僅僅對 Sketch 插件演變的觀察還不足以引發對文題的新思考。真正的機緣來自于最近一兩年做框架和可視化搭建平臺的經驗。仍然回顧最初我認為不能成功的兩個原因，或者說兩個問題，看看經過這兩年，是否發生了新的變化。
順著上一節講到的設計資產的思路，我們先看第二個設計語言與編程語言的差異問題。以組件的維度來統一設計與代碼，其實本質上是對設計的一種補償。既然設計師需要遵守統一的約定來使用或者修改組件的設計，不能再按照個人的習慣，那就讓這種約定的負擔減到最小，即由插件來自動生成，不需要額外記憶。同時將資源的全自動管理作為補償提供給設計師。用工具來管理可以通過團隊的平臺進行共享，如果未來整個團隊需要升級或者統一的修改，就能通過工具來統一完成，不再需要人肉同步。
再進一步，由于組件本身是一個邏輯單位。雖然設計師在設計師可能不遵從邏輯單位，但是在接受信息，與他人溝通時仍然是以邏輯單位為準的。這樣在設計工具上其實可以做更多方便設計師的功能。例如能“快速選擇所有按鈕、表單、幻燈片等組件的圖層進行批量修改該”等。用技術的方式置換掉設計師們以往人肉提升效率的習慣。
這樣，通過轉換一點點角度，主動為設計師做一些改變，第二個問題看起來是可以解決的。
再看第一個問題，產出什么樣的代碼才能讓前端接受。首先，至少在支付寶內部，前端框架的爭論幾乎已經沒有。大家已經普遍接受了 React 及其生態體系。然而實際編寫的 React 代碼中，通常原子類型的組件會被包裝成相應的業務組件，有業務邏輯。而最頂層也只會看到相應的幾個業務組件。不像在設計稿中，所有組件都是原子的，頂層可見的。想到這里時，忽然意識到這也不再是個問題，因為在可視化的搭建平臺中，我們已經使用的是一種平鋪的，頂層可見的組件結構。只要有合適的應用層框架，在頁面結構比較穩定的情況下，它是能解決問題的。如下圖中右下角的組件樹，表示的就是類似圖層的平鋪方式。
我們對平鋪的組件結構，抽象出了數據樹的概念。通過對數據樹的操作，可以完美的控制整個組件樹，也就是整個應用。而一些上升到應用框架層的高級功能，例如表單的校驗等，也是建立在數據樹上的。有了數據樹，實際上就等于有了真個頁面的邏輯入口。下圖展示著在調試模式下，用戶可以直接看到的數據樹。
要進行二次開發，生成的代碼不一定要符合手工編碼規范，甚至不一定要可讀啊！
我們完全可以把生成的界面看做是一個黑盒子程序，只要能保證二次開發者能通過 api 進行控制就夠了！(詳見前端服務化——頁面搭建工具的死與生)。而這種方式所能支持的應用復雜度，其實也就是對應的邏輯編寫方式能支持的應用復雜度，不再和界面本身有關。
至此，兩個問題都已有了解決方案，在可視化自動生成這條路上算是投出了一個新石子。
絮語
從設計到代碼的自動化其實可以看做是可視化平臺的最后一塊補全。截止到今日，之前的可視化搭建平臺已經支持了 56 個系統，在無前端參與的情況下輸出了1000+的頁面。鏈路完成了從研發到自動化測試再到上線。測試工具效果如圖：
如果成功加上設計鏈路的話，可以暢想的頁面開發場景是：
- 簡單的展示類頁面能從設計稿直接上線。
- 需要交互邏輯的，由前端在生成的代碼上補全邏輯。錄制測試用例，然后上線。
- 如果設計有樣式上的修改，不影響邏輯，那么設計改完之后能自動重新回歸測試并上線，不再需要前端參與。
- 如果有邏輯變化，平臺能通過 diff 設計稿得到組件的改動，再通過語意分析得到影響的邏輯代碼范圍。
搭完這條流水線，就會產出足夠規范的樣本，或許就能作為足夠好的人工智能原料，實現讓自己下崗的夢想。
同樣，想要參與到這件事的讀者可以找我來聊聊 ariesate@outlook.com。
文章列表
留言列表
