来自知乎的一个讨论，关于开发和UI不得不说的故事。
提问者：keling
标题：为什么开发不愿意调节UI细节？
问题描述：工作中发现FE不喜欢调节UI细节，觉得这是浪费时间，没有技术性~~该怎样才能让开发同学对此项工作变积极呢？ 想追加一下，想说的是FE没有按照UI设计稿来实现，并非是UI设计稿进行了修改
回答者：陈鑫
反对目前所有答案。
（终于能够像其它酷炫拽的同学们一样用上这句屌炸天的开头了，泪流满面。）
为什么反对呢？从上面的答案来看，大部分回答的同学都是做研发的，所以回答的角度也都是以研发的角度来回来，说来说去不过是“调整UI没有技术含量、浪费时间、不是我的责任范围、你丫老是改设计稿打乱朕的节奏了寡人日理万机没空调整……”
我要说的是，这个角度太LOW了！这个角度基本上就是站在“我就是个搞技术的产品能不能做好跟我没关系，我就是个搞技术的我的价值就体现在我用的技术深不深奥，我就是个搞技术的做没有技术含量的东西不是我的理想，我就是个搞技术的我随时做好了跳槽的准备不行我就换个地方照样写代码”来回答的。
想像一下你要泡妞，对面坐着两个从来不认识的妹子，其中一个漂亮时尚媚眼含秋波（而且胸大），另一个过时土气双目无神采，你选哪一个？对！当然是选胸大的那个！可是我们都知道往往太漂亮的女人容易有傲气，侍候起来不容易，想法幼稚而且要你跟着她的话题走，不太漂亮的反而性格宜人，交往起来地位平等舒服。但是……还是要选胸大的那个！
对于很多产品来讲，漂亮就像是女人的外表，有了林志玲田馥甄邓紫琪波多野结衣松岛枫安城安娜外表的女人会受到更多人的关注。而交互是否流畅、Bug是否很少、性能是否优异等就像一个女人性格是否温婉、思想是否成熟、爱好是否有品味一样，在你和她交往之后才会慢慢体会出其中的好处。但是如果她长得太差，你连交往的念头都没有，谈什么深入了解呢？
认真点来说。
我发现程序员大致可以分为科学家和工程师两类，科学家关注技术是否优越，而工程师关注产品是否完美。和科学家类型的程序员合作一起做项目往往是件痛苦的事情，他们太过关注自己手中的锤子是否先进，却不在意自己敲进去的钉子是否平整光滑不扎屁股，更不要说这颗钉子是不是跟其它钉子对齐了。特别是那些从更早的时代开始做程序员的更是如此，那个年代很多用户体验的技术不成熟，能做出一个能用的东西已经不易，更不要说做出一个性能还算不错的产品了。抱着这个想法走到今天，大多数没有进化应该被淘汰的程序员却反而坐到了更高的位置，开始拿这种过时的想法熏陶小弟。
在百度的时候一个贴吧早期的工程师当时已经是高级技术经理的人跟我聊贴吧的时候说，贴吧之所以能够火起来是因为它性能好，超女那一波活动时粉丝们在网上到处找论坛叨逼叨，很多坛子技术不行撑不住流量就挂了，后来粉丝们发现百度贴吧居然不怎么宕机，就聚集在这里了，于是产品就做起来了。因此结论就是你只要把技术做好，能撑得住大流量，产品就能火起来。
“因此”，他满脸笑容坐在椅子上跟我说，“我们百度知道做了这么多年，在线问答这一块我们很熟悉，我跟你透露一下，我们马上要上线一个叫新知的产品，就像知乎一样，基本上我们把产品放出来就是要告诉国内其它产品：你们不用做了！”
今天如果你在百度上搜“百度新知”的话，你会发现第一个链接已经点不进去了。我想绝对不是因为顶不住疯狂的流量挂掉的。
程序员是一个需要自己做很多判断的工作岗位，而在我的经验里，能够做出正确判断的程序员是非常少的，当然包括我自己也是走了很多弯路，然后在回头看的时候发现自己做错了判断。比如说，后端工程师常常在产品一开始就关注性能指标、上来就搞个分布式存储在后端、然后分布式缓存把所有能缓存的内容都加上去还有极为复杂的失效策略、生怕突然日PV过千万了系统就顶不住了，却不在乎现在日PV连一万都不到，正是精益开发找产品方向的时候；比如说，前端工程师对页面上各个元素的排列对不齐、间距不一致、动画太生硬、字体不佳、特殊的设计元素未能体现等问题视而不见，却全身心地在做自动化打包、页面间解耦，用闭包、元编程、异步来重构原来那些逼格不高的代码。是的，这些傻事我们都干过。我们年轻的时候总以为把技术做好了，就能够顺利地走上人生的顶峰，却没有注意到绝大多数有成就的工程师都是参与了一项非常成功的产品。既使技术能力是一样的，没有Foxmail和微信背书的张小龙还是张小龙吗？
怎么解决？三个字：看，下，面！
一个能够熟练使用html/javascript/css/xcode来实现前端效果的设计师固然优秀，但也是凤毛麟角，工程师不能总指望设计师能够自己搞定全部的前端效果。而设计师在photoshop绘图的时候一定会有某些部分的内容是难以考虑到的，你怎么让别人在photoshop画动画元素的时候就能脑补出各种贝塞尔曲线的效果？你又怎么能够指望设计师在做过场动画的时候对css3的各种transform了如指掌？因此想依靠设计师搞定全部设计工作，给工程师一套完整的设计图，工程师照着设计图一一实现，不交流、不调整、不修改、不返工，说实话，这种童话只存在于ThoughtWorks这样的软件工程咨询公司的承诺里。
所以解决办法无非两种：
第一种是在前端再做分工，把前端逻辑实现与前端界面实现分两个不同的角色来做，并且前端界面实现需要找审美能力较好的那个工程师，最好能够发现其中对界面感兴趣的工程师，你会发现他往往不只是被动地接受修改要求，更会主动提出你都想像不到的修改建议；
第二种就是与前端约定界面调整的时间与工程量，不要一碰到问题就让前端马上改，而是记录下来集中到单独的时间段改，比如说“哥们你看你啥时候有空，我这边整理了一些页面上的细节问题，想找个时间跟你一起一个一个地改了”。
最后一句话，既是给设计师的，也是给工程师的，那就是：首先，你要靠谱！
=====================
（早读课小编注：后来问题修改了若干次，上文看起来有点答非所问，所以回答者陈鑫同学又补充了四点）
标题：为什么部分开发工程师不喜欢调节界面的 UI 细节？
问题描述：工作中发现部分FE不喜欢调节UI细节，可能觉得这是浪费时间，没有技术性、挑战性~~但是对于一个成功的产品来说，优秀的视觉细节是必不可少而且可以加分的。该怎样才能让开发同学对此项工作变积极呢？（不考虑UI稿修改的情况，跟本题有偏差）
回答者陈鑫的补充：
追加四点。
1. 有些人说我答非所问，先申明一点，问题描述有改动，各位可以查看日志，我回答的时候问题处于#37413821 节点。我没时间跟着问题的描述天天改答案来切题。
2. 要说离题，上面很多吐槽一时爽的答案那才叫离题。在我回答的那个节点里题主说明了自己给了FE完整的图，而FE做得跟设计稿有偏差，都没有按照完整的图来做。那么我的回答当然是先分析为什么会出现FE不按照完整图来实现？这背后的心理动机可能是什么？（感谢很多其它回答者，你们的答案一一印证了这些心理动机。）答案的前面部分分析相信题主理解之后可以自己思考如何去提高FE在实现的时候多关注界面细节的意识，最后一部分基本上已经是从实际操作层面来说如何解决问题了。谈何离题？而这些吐槽回答者却莫名其妙地脑补了“设计师反复修改图连稿都定不了”、“肯定会出现FE按照你的设计做完之后你又要别人去改”、“你丫肯定站在FE背后指指点点把别人当人肉PS来用”之类的各种情节，或者一副高贵冷艳的模样说“设计的质量决定了我实现他的热情”，请问你从哪个地方看到题主的设计质量有问题了？
3. 别嚷嚷什么设计师没有标注出各个顔色的RGBA值、各个间距的px值，作为FE你连xscope或者FScapture都不会用请问你平时是肉眼看出顔色和间距的值的么？过去的七八年里我实现过很多设计师给的设计图，标出RGBA值和px值的有，不标的也有。说实话，在实现的过程中没有任何明显差别，直接看设计图上标的数值与自己把鼠标移过去取值，效率上如果有影响，也比不上不用snippet插件直接一个字母一个字母地敲background-color:transparent来得多。明明实现得有偏差却把责任全推到设计师没有标明详细的间距宽度什么的，在嚷嚷这的时候你能不能先扪心自问一下，你的代码里该写的注释都写了么？
4. 绝对的分工明确只存在于生产流水线之类的机械劳动里，稍微高级复杂一点的工作都不可能有非常明确的分工界限，看得出很多的人团队意识跟工厂里面那些拧螺丝钉压塑胶壳的初中毕业生没什么区别。比如有人说，设计师或者美工（甚至还有产品经理！）应该把图切好，标明各个值再交给FE。远的不说，说一个例子。我原来在百度时一个我很佩服的同事在做前端的那段时间里，写了一个工具专门将各种小图片合在一起自动生成css sprite所需的整图和css代码，他甚至还研究了一些论文以便论证自己所生成的整图占的面积是最小的。请问这种事情应该是FE做还是设计师（或者产品经理？）来做？
团队合作的其中一个意义就在于当你的队友出现能力不足或者失识的时候，自己主动地补位并掩护，而不是指着他说：都是他的错！
知乎原帖：http://zhi.hu/22lB
评论回复