前端工程师，如何更顺畅的和后端工程师合作？

tangbozhu810711

其实前端工程师最郁闷的就是遇到刚毕业的设计师。或者在设计上还不错的。遇到这种怎么办，你要自己把控住自己。首先你在切图上的时间会加大，这是没有办法的。因为我遇到过一个做过设计8年左右的。他设计的PSD图片到我手里我都不用去切图，他已经把图片全部打碎你到时候直接把那个图层抓出来就好。但是这样的人很少这就要你耐住性子去自己切图。如果他不去适应你你只能去适应自己。这样导致一个问题就是和后端的配合工作投入就会减少因为前段花费的时间太多。在这种情况下你就可以和后端的哥们商量商量，你可以让他们在Js功能上多写一下。让他们也有成就感。效果的JS还是你自己来写因为这些东西对于后端来说没有什么。
如果你遇到牛叉的设计师和悲剧的后台。你就要多写前端功能，你可以让设计师来帮你切图这样就达到平衡。大家都在一起工作没有所谓的我不做这一块这一块不是我负责的。实在不行你只能去找项目经理协调。
如果你遇到前后端都给力，我只能说哥们你太幸运了。但是如果你是菜鸟只能加加班自己把自己的技术提升上来这个没有人能帮助你了。
如果是前后端都不给力，我只能说你在的公司也够悲剧的。这种情况下你只能和他们一起加班慢慢做东西了，这个过程是没有办法的办法。
其实前后端配合最主要的一点就是你在功能完成的前提下尽量让页面的设计理念不丢失这是前段最根本要完成的。

cornetto_210

职责定义清楚就好了。后端只管提供数据。改 js 肯定不是后端该做的事。严格的说，后端用于输出视图的那段代码，虽然他位于后端程序的代码仓库，但其内容也应当由前端完成比较好。

后端要完成的是与用户界面完全无关的工作。

看起来我赞同的方式正好是 安江泽 说的那种方式。

Coues-pb

问题的「合作」指的是团队沟通？还是技术实现？
@Fenng 的解答是从团队沟通角度出发。

我只补充一下技术实现角度的经验——

后端只提供内容（数据）。
至于内容（数据）的包装格式是用 JSON、XML 还是直接用 HTML（比如服务器动态脚本生成的页面），都可以。
如果是 HTML，因为是通用标准，就需要事先约定好容器的语义规范。
JSON/XML 因为不得不事先约定，所以一般不会发生语义模糊的情况。

至于如何赋予内容以样式（CSS）、行为（JavaScript），则完全由前端负责了。

jixusheng1983

在一起…

anthekin

我觉着，如配合的，最好是重服务端，轻客户端，两者彻底分离，服务端，只需要提供处理完成之后的数据，json,xml等，前端则负责所有的展示逻辑部分，请求，解析，然后按服务端给出的值，来进行下一步的工作。这样的好处，就是，两者都不冲突，服务端的人，可以写他们自己的，他们把服务端代码重构了都行，只要给前端提供服务地址即可，而前端的开发人员呢，前期，可以做一个假的地址来进行编程，各搞各的。

sunkang0617

一个前辈和我说过一句让我受用蛮大的话，让专业的人做专业的事情。既然选择合作，选择把功能都接口化完成，那么就把接口细化，开始做之前先定一个简单的接口规范，比如你要后端吐什么，后端要你传什么，形式是1,2,3,4.还是a=b&c=d，亦或者a+b|ee-rr什么的，然后开始搞就行了，中间又变更互相问一下，你那里好改么，好改，不就哦了..其实只要大家相熟，没有同行相轻的看法，关系融洽，你信任他和他写的代码，上边的话，都是浮云。

34456948

给你个好建议  我在项目中的经验  前后端完全解耦  后端只管提供数据 前端管数据的实现
大家先一起开个会 吃个饭 或者打个dota  搞完之后 两边都确定一下数据的格式 写一个纸面上的文档 要哪些字段 基本的数据结构 最好是用json ，比如确定下来一个这样的结构
{"name":"viking","age":"26","hobbies":[{},{},{}]}; 双发各自保留一份

然后前端根据这样的一些机构弄一份假数据（json文件）不用等后端做好就可以开始做项目  等后端这边开发完成(开发过程中也要多做沟通 大家一起做做review  保证接口返回的数据和初始的时候一样 如果发生变化 前端可以更新自己的假数据 达到和后端同步) 只要把相应的url 换成后端工程师提供地址即可 这样可以达到效率的最大化

最后还是插一条广告吧，如果这样做，你最好试一试backbone.js 单页面和前后端分离这样结构下非常好用的库  如果你考虑这样实现 可以试试backbone.js

MP5Y

不要分前端后端，然后偏向前端，就可以了

fanxiao98

要看业务的复杂度。简单的开发只要套个VM模板就能搞定的，相信你必定有过经历，怎么做得模块化，让开发的VM能拆分出通用的模板是需要多考虑一下的；如果业务比较复杂，主要是异步通信比较多的，那建议是这样来做：前期模拟好异步API，建议是用PHP或者类似的后台语言模拟出不同场景下的返回数据如果前台交互复杂，那么尽量在前台去处理大部分业务逻辑，比如使用前台的Template，虽然会一定程度增加前台维护的开销，但是总比时不时找开发去改代码要快捷许多。前后端的耦合，大多数情况下，更侧重的是：数据。初期未动手写代码之前，多想想业务逻辑，画图来理顺业复杂的业务逻辑，提前发现那些未考虑到的异常流（往往是这些异常流，到后期会冒出很多问题，不断地找PD确认，不断地修改，很费时费力），一切想明白了以后，写一点伪代码搭好整个代码的框架，然后再细化地去写每一个具体的逻辑。另外，不要吝啬写文档与注释的时间，没有时间那只是一个借口，自己的代码，一周以后再来看，有些逻辑都记不得了，谁都有过这种经历。我的一个痛苦经历是接手的代码没有文档，也没有注释，也没有拆分模块，整整花了三天才把别人的业务代码看明白了七八分，后期改版时，依旧有那么多业务逻辑是我不知道的，没有文档，业务交接就会带来这么多麻烦的事情。

QVB6196

关键在于接口的定义