在开发的时候，我们往往会另外与产品经理进行细节化的讨论。但是这种讨论结果，我们并没有记录到产品原型里面或者需求列表里面。但是过了几个月后，我们自己往往会忘记我们当初为什么会讨论出这样或者那样的一个细节。所以一切的需求必须是根据的。从另一方面来说，也保障了双方的利益，别等到出问题的时候，不知道是谁的责任，而在这一方面，程序员往往很吃亏。
6.对自己的程序有一颗艺术的心
有人说过，当需求影响到代码扩展性的时候，会首先砍需求，而不是改代码！在一定程度上，我是认同这句话的。在我看来，程序是一件思想上的作品，要达到艺术的境界，从功能、体验和逻辑上都必须是合情合理的。就像一件艺术品一样，看起来是浑然天成的！因为一件看起来很“丑陋”作品，一定是不符合人的逻辑和习惯的。
写到最后，感觉绕回到程序员自身了。其实跟产品经理沟通，最重要的是要明白到：我们是在解决问题，而不是在制造问题！主要抱着这个核心，一切问题迎刃而解
一般来说和后台沟通没那么多的麻烦,约定好规则后,一般来说你们是通过api来沟通的,但当你调试接口时,出现一些未知的,你感觉不是自己问题的时候,及时的沟通后台是最明智的。
责任划分
相信大家在这一点上都深有感触,因为前端是最后一关,所有的需求都是在前端手里变成一个具体的产品的,这样也就导致你很容易变成背锅侠,导致项目延期的情况有很多种,设计图不及时,后台数据出现问题,产品临时改需求,如果你不能证明是这些问题导致项目延期,这个锅你必背无疑,唯一的方法就是--à口头确认--à发email到责任人确认--à通知上级,千万不要觉得这个麻烦,出问题的时候会比这个更麻烦的,
写不动了,以上就是个人爬坑后对前端的一些理解(ps:虽然我还在坑里),也算对自己工作的一个总结吧,写的比较絮叨,不喜勿喷,最后祝大家2018升职加薪,找到女朋友!!!