如何评价 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；设计师则会觉得设计主导更靠谱，因为代码的成本过高，灵活性太低，限制了他们的创造性和工作效率。这里面本质上是设计作为创造性工作和实际开发工程化的工作方式之间的冲突。 能够跨界并且两边都很深入的人很少，一方面是能够跨越两种思维模式的人本来就少，另一方面是以目前软件工程和设计的教育体系来看，这样的人才难以体系化地量产（国内尤其）。如果从教育环节就开始针对性的培养，或许将来某一天这样的人会多起来。但目前而言，这样的人即使在国外也属于稀缺物种，而依赖这样的人才的设计/开发体系，也只有在极少数有条件的公司才有运行的可能。