如何評價 Airbnb 發布的 React Sketch.app 工具？
很有意思的想法和實踐。一邊有人在嘗試用設計工具生成代碼（目前為止都還沒有太靠譜的），一邊有人在嘗試用代碼生成設計稿。本質上都是在試圖打通編程和設計之間的隔閡。對於這個大命題，後面再細說。
具體到 Airbnb 的這個工具，其實他們有很切實的需求。首先公司大了，需要維護一整套設計語言系統；（比如 Material Design 之於 Google，AntDesign 之於螞蟻金服）同時這套系統不會是完全定死的，會不斷地進化、修改。另外，基於這套基礎系統，會針對各個具體產品、BU 衍生出很多子系統。問題就在於，每次要改基礎系統里的組件或是規則的時候，就會不可避免地產生連鎖反應，導致所有的子系統也要同步修改。
另外，到目前為止，類似的設計體系在設計文件和業務組件代碼上都是分離的。設計師維護一套 ai 或者 sketch 文件，工程師維護三套組件代碼（如果用了 RN 或者 Weex，理想情況下可以只維護一套）。也就是說，source of truth 有兩個甚至多個。理論上來說，這會導致很多重複工作量：任何改動都需要設計師和工程師在設計稿和多份代碼之間做同步。Airbnb 的這個工具的目的就是讓基於 React 的代碼成為唯一的 source of truth，通過一份代碼渲染三端組件 + 生成 sketch 文件。
野心很大，不過這帶來一個問題：代碼到設計稿的生成是單向的。這意味著以後任何對設計的改動必須以代碼的形式來執行，也就是設計師必須得會寫 React...
說來也巧，昨天這個項目的負責人 Jon Gold 在推上跟人爭論，他說覺得設計師學不會 React 的人是在小看設計師。說實話，作為一個在設計和開發之間有點跨界的人，我對這樣的系統是很歡迎的。但是你要說讓隨便一個設計師學會 React 是個很簡單的事情，還真有點何不食肉糜的感覺。
總的來說，我對這套系統的看法是：想法很有前瞻性，但落地對團隊要求極高。主要的原因在於這套系統就是想用一套生產環境代碼通吃，那麼組件中不可避免會混雜相當多的交互和工程細節。從工程師的角度說，一個普通設計師學了點 React 基礎，你放心讓他改么？如果這個設計師的代碼水平都可以直接改生產用的組件了，這樣的人又有幾個？客觀來說，能夠負責設計系統的設計師，肯定已經得是設計師裡面邏輯思維能力很強的那種了。但這樣的以代碼為 source of truth 的系統，負責基礎組件的團隊必須個個是設計和開發的高級跨界人才，衍生子系統的設計師也得有初級工程師的代碼能力。
回到之前更高層面的命題：設計和代碼的結合，到底應該是設計主導，還是代碼主導？如果透過工具看產出的本質，最終生成的其實都是一堆數據結構。但是不同職位的人會有不同的看法。工程師會覺得代碼主導是更靠譜的，因為代碼本身描述數據結構更精確，也更 scalable；設計師則會覺得設計主導更靠譜，因為代碼的成本過高，靈活性太低，限制了他們的創造性和工作效率。這裡面本質上是設計作為創造性工作和實際開發工程化的工作方式之間的衝突。
能夠跨界並且兩邊都很深入的人很少，一方面是能夠跨越兩種思維模式的人本來就少，另一方面是以目前軟體工程和設計的教育體系來看，這樣的人才難以體系化地量產（國內尤其）。如果從教育環節就開始針對性的培養，或許將來某一天這樣的人會多起來。但目前而言，這樣的人即使在國外也屬於稀缺物種，而依賴這樣的人才的設計/開發體系，也只有在極少數有條件的公司才有運行的可能。最早關注到這方面是從 mschoening 的這幾條 Twitter（需翻牆）開始
https://twitter.com/mschoening/status/847496408168976384https://twitter.com/mschoening/status/847856021938724865https://twitter.com/mschoening/status/847506348447219713
這裡展示了一種可能，隨著 Sketch 43 的發布，由於文件格式完全開源和 JSON 化，前端代碼和設計稿的互相轉換和同步是可行的道路了。
然後有人提到 jongold（react-sketchapp 作者，Airbnb 工程師）正在做一套東西，能夠把代碼渲染到 Sketch 文件中。當時 mschoening 的說法是：
I』m not very interested in the inverse but some folks are working on it.
接下來就是 react-sketchapp 的釋出了。我們可以在項目 README 中看到，這是一個設計師使用 React 語法寫視覺稿的項目。
官網也羅列了你現在可以用這個做什麼：
- 管理可復用的設計資源。
- 使用真實的數據和組件進行設計。
react-sketchapp 希望你用 React 代碼來製作和管理 Sketch 視覺稿以及相關的設計資源（比如變數化的色彩系統和字體大小等，很容易的統一修改樣式同步到所有組件）。
說實話，這個東西正式發布的時候，我還是有點失望的。按照現有的工作邏輯，設計稿是上游，前端代碼是下游，如果已經能寫 React 代碼了，我為什麼還需要出設計稿，不如直接出原型產品。大多數人關心的是如何從 Sketch 導出 React 代碼，從而解決現有流程中的幾個問題：
- 保證設計的可行性：解決設計難以實現的問題。
- 前端代碼實現的還原度：解決實現和設計不一致的問題。
- 節省 UI 的開發時間：工程師可以把更多精力投入在數據和流程上。
對於這個方向，react-sketchapp 也給出了自己的看法，可以看出 Airbnb 想解決的問題和我們大多數人遇到的問題不太一樣：
Is there two-way binding? Can I generate React components from Sketch?
Nope.
Isomorphisms are compelling but our focus is on tools that we can use day-to-day to improve the productivity of designers and engineers working on large-scale production applications.
Getting production-ready semantics out of Sketch is more difficult than generating production-ready Sketch templates from React components.
Our solution is to keep our our design system』s source of truth in code, and use react-sketchapp to compose consume it.
To edit our design system, we are free to leverage any technology that can create React components, or be compiled to JSX, such as:
React-centric IDEs
in-house design tools that are tailored to our workflow (whilst being backed by data, version control semantic versioning)
writing React components in text editors with our fingers其中很重要的理由是，從 Sketch 到 React 代碼的轉換在實現上有難度，對製作 Sketch 的語義化要求很高。因為本質上設計師做 sketch 是畫而非帶有邏輯和層級關係的寫。
我們自己內部在嘗試做一個產品遇到了類似的問題。我們希望設計師直接基於已有的組件和模板進行在線組裝設計，跳過設計出稿階段，直接導出高保真的代碼片段。在研發和試用過程中發現，設計師對於頁面的樹形結構很難理解，上手成本較高，而且新平台的體驗很難做到像 Sketch 這種專業設計工具那樣順滑。因此我們也觀望和探索從 Sketch 直接導出 React 這個方向，相信社區中也有很多人有類似的想法。
那麼 react-sketchapp 這個項目的現實意義是什麼？
按照 jongold 在 Painting with Code 里的說法，他們似乎創造了一個新職業（設計工程師？）。在這種模式下工作的設計師寫代碼，有完整的工作流，使用真實的業務數據，按工程化的方式管理整個產品的設計系統，這也是 Airbnb 的設計團隊在嘗試的新的工作方式。雖然對於大多數設計團隊來說這種模式目前很難落地（缺少這樣的人），但是它的確打開了一個新的窗口和思路，在智能設計這個風口上，更多和工程結合的設計工具和產品會在 UI 設計領域的社區中展露出來。
很喜歡 jongold 引用的這段話：
「The strange and beautiful truth about the 『adjacent possible』 is that its boundaries grow as you explore them. Each new combination opens up the possibility of other new combinations」
正好最近正在玩 Sketch 43 的文件開源並在開發的過程中讀過這個項目的源碼，所以這裡有一點不成熟的小想法：
這個項目就是把 React 代碼渲染成 Sketch 文件，得益於 Sketch 43 源文件的開源：New file format in Sketch 43。實現的樣式和布局是個子集，把傳給 React Component 的 style 轉成了跟 Sketch 43 源文件內 pages JSON 文件里同樣的格式 ，再調用 Sketch 暴露給 Plugin 的方便的 CocoaScript 介面去做接下來的渲染操作，所以談不上很複雜。可以把其想像成一個 React Component -&> Sketch pages JSON 的 transformer，然後把生成的 json 文件和相關的靜態文件打成 zip 包後用 Sketch.app 打開，然後通過 CocoaScript 轉換一下無法直接用 JavaScript 生成的樣式，最後就大功告成了。
這個由編寫 + 組織 React Component 代碼去生成 Sketch 文件的方式去替代原本的所見即所得的生產方式感覺在某種意義上是種倒退。當然在某種結構化性和重複性比較強的設計場景下可能會有明顯的好處，但設計的最終目標不就是杜絕結構化性和重複性嗎？
最近正在做反方向的工作，這才是真正具有挑戰性的，Sketch 其樣式之複雜就不多說了，最坑的一點是它開源出來的字體樣式還是未解碼的 MSAttributedStringFontAttribute… 在前端 base64 解碼後也完全無法讀（所以前面會用到 CocoaScript），現在提取文字顏色我還是用的很 tricky 的方式…
為什麼大家都在談論設計師學編程的問題呢？我覺得這種工具的使用場景不是這樣的啊。
其實也不是我自己認為。事情是這樣，某次參加一個技術分享，主講者介紹了一套自研控制項庫，附帶了控制項到 svg 的轉換器。主講人對於轉換器的場景是這樣解釋的：
讓設計師不需要憑空設計交互，直接從控制項庫里挑選即可，和前端溝通成本會降到最低。
我想了想，換成人話說：這套工具的目的是「規治」設計師，讓他們盡量不要設計出控制項庫里沒有的東西來。
除非設計師自己把控制項寫好——這才涉及到設計師編程的問題。終於有這麼個工具了。自此全棧設計師又增加了一個項目。
不過原來前端就是切圖的，這種技能終於又可以回到前端這個技能圈裡了。
我一直覺得，對Web開發來說，端對端交付大於一切。
另外，雖然代碼可能對設計師不友好，但代碼管理一定優於其他方式，因為容易版本控制和協作。
你看現在經常說pipeline as code之類的，任何東西用代碼的形式管理都可以大幅擴展和提升效率。
PS：主要PS太特么難用了。
Blend for Visual Studio很多年前已經解決了這個問題了，而且它還更進一步，設計師和程序員可以不斷的協作下去不斷迭代，哪怕是大綱也不要求你一次性就要完成的。然而事實證明，這事主要還是看公司制度，跟工具的關係不是很大。不願意合作的，仍然還是扔你psd和ppt（主要是做成動畫，惟妙惟俏我只能說，那幫UX用起ppt真牛逼）讓程序員自己想辦法復刻。願意合作的，才會從工具里得到好處。
什麼，你說要在瀏覽器裡面跑才算？當然可以跑！
React Sketch 是一款非常棒的工具，能夠讓設計師快速幫助我們完成基礎組件的設計工作。
當我們已編寫一大堆基礎組件時，遇到改版時，設計師可以協助修改部份基礎組件配色、樣式與結構。更有效的了解我們的工作。
當然我們前提是必須很樂意地指導設計師學習相應的React（JSX）、HTML/CSS等知識，感謝他們幫助我們消化掉一部分我們可能不是很擅長的設計規範相關工作。同時增加一點點時間Review設計師開發出來的代碼。
國外已經有設計師在使用它來完成部分基礎設計規範工作，更盛讚它更高的設計效率。
更多評價（翻牆）： https://twitter.com/jongold/status/856922487631642624
同時也可以了解更多 React Sketch 如何幫助 Airbnb 設計師工作的：Painting with Code
同時也看到，圍繞著React生態哺育出了很多優秀工具，例如 infernoJS / preact，越來越多人使用它們在移動端生產環境代替React，因為它們在 SSR 上有2-5x左右的性能提升。js parse時間更短，性能更高效。還有 ReactVR，而 React 16 也將在今年夏天推出，讓人興奮和期待。
相關爭論：https://twitter.com/jongold/status/857738765913120768
另外我想說 PSD 生成代碼，也有很多比較靠譜的實踐，比如 http://h5.baidu.com 支持一鍵導入PSD。
很多時候我們看到新的事物，應該以正面的態度去看待新事物的優點及缺點。而不是過度解讀別人，讓人感覺到深深的惡意以及噁心！
做出一個高效組織的設計系統並且進一步彌合開發和設計之間的鴻溝，是很多團隊都想做到的事情。有的團隊在試圖通過 Sketch 自動導出布局，有的團隊如藍湖在優化 Sketch 的項目管理。大多數這些努力都是圍繞基於視覺的設計軟體 Sketch ，總體思路都是試圖讓開發的邊緣靠近設計，而很多項目都證明了讓開發貼近設計有著越來越高的邊界成本。
Airbnb 開創了一種新的可能——讓設計面相開發，讓設計行為本身就在前端框架中發生，同時還能一併解決經典設計體系所固有的系統管理成本過高的問題。面相開發設計是否是未來設計到開發的終極答案？
或許有一天，熟練掌握前端代碼，在前端框架下設計，是每一個互聯網產品設計師的全新工作方式。
本來昨天發布看沒有人問相關的問題，就初步感受了一下，寫了個專欄，有更多興趣的可以移步去看看...
[New Stuffs] UI 設計師未來的全新工作方式
改為匿名不重複污染時間線
不會設計的前端開發不是好前端···
我的想法是有沒考慮過可以直接上交互了，哈哈哈哈
看五年之後幾個人用吧沒法雙向實時編譯是現在的硬傷。
Coding本身是重邏輯反直覺的，而設計某種程度上說是基於一定的直覺和經驗快速試錯的過程。寫代碼這個試錯環節成本還是有點高。理想中的設計工具：
想法有了再給我100個程序員讓我改變世界
1.（圖形界面和代碼雙向編譯）
2.跨文件共享樣式
3.json為組件傳參
4.Ai設計輔助：匹配設計模式和素材收集
5.彈性柵格
6.簡單的版本控制
7.頁面路由描述
8.為組件添加一些條件控制語句大量前端要失業了。。。。
對於絕大多數國內設計師來說，這個過程絕逼是搞反了……（╯" - ")╯︵ ┻━┻當年 DW不也是在做這個事情嗎？
這種東西要求使用者即會代碼又會設計。
終究小眾。寫了篇文章
http://mp.weixin.qq.com/s/SG4v_a2buEpZ5nSTb_0tNw總結了下優點，另推薦用react native 的deco IDE。
終於把我想要的東西實現了：設計和代碼為一體。
以後程序員和設計師的角色界限會變得模糊，未來會再也沒有設計師和程序員的溝通障礙，世界大同。React Sketch.app 是 Airbnb 為自身打造的工具，不適用於其他團隊。
設計是感性和理性的結合，各行業們的設計師們通常也是用可視化的圖形工具。比如：室內設計師使用3Dmax、 CAD；藝術家們使用 ZBrush 來完成數字雕刻；做遊戲的使用 Unity 3D、cocos2dx；平面設計師使用的 Adobe 全家桶。
如果 React Sketch.app 的目的是打通設計和前端，我認為反向工程要更合適。做一套基礎控制項，使用空間名來定位功能。比如 sketch 建立一個 navbar 的組，設置 background 元素、哪裡是 button、哪裡是 icon，解析出來，對應到三端。sketch 當前版本（461以上）也同樣支持自適應視圖的設置。這樣設計對 UI 進行了調整，只要解析 sketch 文件就可以做到三端統一。設計的精力可以放到對 UI、UX 更深層次的挖掘，而不是整天跟前端溝通和撕逼。
讓設計師專註於設計，工程師專註代碼。
（反向工程應該是可以實現的，sketch 本身就是通過 json 存儲的）
如果他能雙向編輯，那麼如今很多UI設計師都將失業，我相信，雙向編輯這一天很快會來的
還不如先把手頭工作做好?
推薦閱讀：
