标签：nps market 比较 角色 day 类型 研发 cts 并且
三年前刚开始做 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 代码，我们在实际代码的编写中，通常原子类型的组件会被包装成相应的业务组件，有业务逻辑。而最顶层也只会看到相应的几个业务组件。不像在设计稿中，所有组件都是原子的，顶层可见的。想到这里时，忽然意识到这也不再是个问题，因为在可视化的搭建平台中，我们已经使用的是一种平铺的，顶层可见的组件结构。只要有合适的应用层框架，在页面结构比较稳定的情况下，它是能解决问题的。
我们在平铺的结构中，抽象出了数据树的概念，所有对视图的修改都是对数据树的修改完成的。而应用框架也是建立在数据树上的。而数据树本身是综合了用户对组件的命名而生成的。因此，数据树，或者说用户对组件的命名，可以看做是页面逻辑的入口。
有了这个结论。不禁回首发现，要进行二次开发，生成的代码不一定要符合手工编码规范，不一定要可读啊！只需要保证用户能以某种方式编写业务逻辑就够了！(详见前端服务化——页面搭建工具的死与生)
而这种方式所能支持的应用复杂度，其实也就是对应的逻辑编写方式能支持的应用复杂度。
至此，在可视化自动生成这个题目上算是投出了一个新石子。
从设计到代码的自动化其实可以看做是可视化平台的最后一块补全。截止到今日，之前的可视化搭建平台已经支持了 56 个系统，在无前端参与的情况下输出了1000+的页面。链路完成了从研发到自动化测试再到上线。测试工具效果如图：
如果成功加上设计链路的话，可以畅想的页面开发场景是：
简单的展示类页面能从设计稿直接上线。
对于可以覆盖的，需要交互逻辑的，由前端在生成的代码上补全逻辑。录制测试用例，然后上线。
如果设计有样式上的修改，不影响逻辑，那么设计改完之后能自动重新回归测试并上线，不再需要前端参与。
如果有逻辑变化，平台能通过 diff 设计稿得到组件的改动，再通过语意分析得到影响的逻辑代码范围。
搭完这条流水线，就会产出足够规范的样本，或许就能作为足够好的人工智能原料，实现让自己下岗的梦想。
同样，想要参与到这件事的读者可以找我来聊聊 ariesate@outlook.com。
标签：nps market 比较 角色 day 类型 研发 cts 并且
原文地址：http://www.cnblogs.com/sskyy/p/7813943.html
