前端因为像素还原设计稿而离职，这是个别现象吗？ 第1页

看了题主的描述，我觉得题主项目组的问题，主要还是规范缺位。

作为前端，一般的项目我们都不让设计师做视觉设计，交互评审通过直接开工，这样就不存在视觉还原问题啦（狗头）。

我是从事“工业化”前端页面生产的，对页面视觉效果，追求端正重于美丽。注意我用的是“生产”这个词，而不是开发或研发——对于需要大批量交付的非创意产品，如果你把网页做出“研发”的味道来，那你这个产品好不了，要么成本爆炸要么进度爆炸要么质量爆炸要么一起爆炸。

那么，这样的产品怎么做呢？简单地说就是四件套：

第一，PRD/FRD文档，详细描述了产品逻辑和功能需求，包括主要的使用链路也都在里面，让你明白你在做一个什么东西。

第二，交互设计文档，包括页面示意图和分镜图，以及跳转链路和必要的标注，让你明白你做的东西大致长啥样以及怎么用。

第三，Design Pattern Library，简称DPL，包含标准样式集（边距/字体/色值等），组件设计清单以及使用样例，标准layout，以及常见场景的交互案例（供设计师参考）。

第四，标准物料库，即严格按照DPL实现的组件库，css样式库，以及常见场景的模板库。

在这四件套的基础上，前端工程师的理想工作流程是：使用标准工具初始化项目☞创建必要的代码文件☞按照交互设计将物料堆到代码中☞编写业务逻辑（数据流）☞提交测试☞bugfix☞发布上线。

这里就涉及到像素级还原的问题了：如果我通过堆物料做出来的页面无法像素级还原设计师的设计，那一定是设计师的锅——你怎么设计出跟规范和物料不一致的页面的？

下面是QA时间——

问：这样做项目，设计师岂不是没有发挥创意的空间了？

答：是的，没特殊情况，不允许发挥。

问：没有视觉稿，如何避免前端实现的随意性？

答：DPL提供强约束，物料库提供低成本方案，尽量不让前端进行样式调整。对于新场景，也要求提供视觉稿，但需要遵守DPL规范，通过将DPL实现为sketch等设计工具的插件，可以让设计师方便的实现这一点。

问：这样做项目，还要设计师干什么？

答：设计师的主要工作是设计DPL本身，包括品牌视觉传达，组件交互/视觉设计，常见场景的交互方案设计和优化，以及面向业务线的DPL增强等。具体页面的设计也是设计师日常工作的一部分，尤其是一些重点高频页面的设计，但这部分设计后续也要逐步收敛到DPL当中。

问：这种做法适合C端产品吗？

答：C端不等于天马行空，也要看具体业务。比如各种h5创意广告，肯定不适合这样的做法，但是像知乎这样的网站，很大程度上是适用这种做法的。并且，规范化设计是个渐进的体系，不能100%适用，不代表100%不适用。

问：这样的做法除了让前端更省事儿，还有别的优点嘛？

答：体验优化是一个过程，而不是一锤子买卖，规范化设计，有利于提高项目的整体交付质量，也有利于后续体验优化在既有页面中落地，使得产品具备持续演进的能力。另外，由于各种智能终端的普及，多端应用已成为业内标配，基于规范，设计师可以通盘考虑优化体验，避免低效工作。

我一直在想软件开发领域啥时候来个钓鱼的，提问者就填补了空白……

你就是那个前端，因为不爽设计师来反串黑，恕我直言这实在是太low了。

不懂前端的设计师不是好的艺术家这句话并不是玩梗，事实上前端技术之于UI设计无异于颜料画笔之于画家，哪有颜料和画笔都不会用的画家呢？这一点是毋庸置疑的。

但是所谓的像素级还原很多时候并不是什么吹毛求疵，而你说的这种典型的一面之词我是不会评价的。

你知道编程领域的函数是什么吗？

不知道，那么这个问题没啥好回答的了，请叉掉。

知道的话，那么ABI就是描述，函数名如何存储，函数参数类型如何存储，的接口。

一个程序要想调用其它程序编译出来的函数，那么就必须知道其ABI接口。

C语言具有优秀的ABI兼容，因为主流C编译器编译出来的函数，ABI接口大都相同，所以用C语言写的库能方便的被其它程序调用。

C++一般不具有很好的ABI兼容，因为每个C++编译器编译出来的接口可能不同，导致了你无法调用其它人用C++接口提供的库函数。所以C++函数往往强制使用C的ABI用于给其它程序调用。

当然，除了函数，ABI还有其它一些东西，有兴趣的可以查阅更详细的资料了解。