前端的痛点之与后台和产品经理的协作

前端又称Web前端开发工程师,主要负责制作页面,设计交互,对接接口.与UI设计师,产品经理,和后台开发人员协作.

根据UI设计师的设计图 切图,使用CSS制作高保真页面.

根据产品经理需求,完成页面交互,路由跳转,功能实现,

根据后端开发提供的接口,对接接口,数据,联调功能.

根据.....

总的来说,前端开发人员是一个很苦逼的工作,三个"根据"完全把前端开发人员的主动性和创造性完全打压下去了.你想先做页面,不行,你得根据UI设计师的设计图来,你想先设计路由,实现交互,后来产品经理把这里改了,你想准备对接接口,后台人员还在设计表结构,MMP,还能不能好好工作了,还能不能好好的愉快的编码?

我常常痛恨那些蹩脚的产品经理,只知道抠图,完全没有一点自己的设计思想,逻辑混乱,文档参差不齐,描述含糊,一份文档看下没有几个能做的,有的甚至只是截个图,说,实现一个图片一样的功能,每次听到这样的话,我就想啐它一脸,没有一点脑子.

就拿一个表单页面来说吧,我们的产品经理总是那以前的页面,截图下来,改几个字,也没有额外的话,没有什么限制,你问他,他才会说.真是让人火大.

如果让我设计一个表单页面我会这样设计

首先这个页面的入口和出口,从那里进来,从那里出去

其次字段的默认值,字段的限制规则,比如不能超过多少字节,错误弹窗怎么提示,还有内外联动,以及弹窗的联动,必填,选填,交互.页面上的关键按钮的功能都要写清楚.

其次产品经理应该有个公共的设计原则,比如,表单上的取消按钮就是返回到列表页,或返回到上一级,比如列表页灭有特殊说明每页都是显示15条

原型图和页面规则逻辑不要放在二个文档里,这样看起来很痛苦的.对于那些原型图只是简单截图的需求文档我心里是崩溃的.为了提高彼此的效率,产品所有的规则,要求,逻辑都要写在文档里,以便追踪,查看.如果只是口头传述,不能保证别人再问第二遍,不能保证所有需要知道这个改动的人员都在场,测试,后台,前端,交接人员,DB,运维,等...

以上所写的一些抱怨,要求,都是我在工作中遇到的,可能对于一些刚入门的产品经理有一些指导意义吧,或许没有,如果产品文档一直改动,要么是 产品定位不准确,要么是产品经理做的还不够好.总是,受苦的还是开发人员,对于上线前还改需求的我会回敬:next version..... 顺便一提,其实我们项目专员(就是产品经理,直接负责出需求文档的)对我们还是挺不错的,陪我们加班,给我们吃的,我经常质问她需求的问题,她也不会生气.一个很好的女孩子.

说完了我会产品经理再来说说和后台开发协作的糟心事吧

现在很少项目是前后端不分离的啦,所有数据都是前端通过接口请求获得,这样后端就要写接口文档,

一个接口包括六部分

请求地址

接口名称,描述

请求数据

返回数据

数据解释

示例(重要接口需要)

请求地址要使用比较能标明操作的词语组成,让人看到接口,大概就能猜到它是做什么用的,这不用多说了,重要的是下面几个部分.请求参数,对于列表页,根据id获取详情页,这些接口都有固定的请求数据,比如页码,每页多少,主键id 对于这些接口请求数据相似性很高的接口这些需要单独整理出来,页面是从0还是从1开始, 而不是不写,让前端调取接口时自己猜.整理出来也有助于规则统一.更好维护,接口的描述要准确,是在如果不写该接口应用在那个页面,应该写应用在那个或那些功能上.请求数据一定写类型,string int array object 写清楚才足够显得专业,注重细节就会减少bug,减少沟通成本,魔鬼隐藏在细节里.除了请求参数外,重要的还有返回参数,返回参数都是有一个基本格式的,标明接口请示是否是正常返回,尝试用自定义的状态码和错误消息使用约定的属性,如{errcode:200,errmsg:'ok',data:{}},这样前端就可以直接使用公共的方法来处理每个接口的标识状态码 改重定向的重定向,该弹窗的弹窗,出来数据的基本格式外,接口文档还应该让前端,清楚地知道数据结构,而且经过尽量减低数据结构的层级,以避免不必要的麻烦,后台在数据返回前端之前,可以先处理一下数据,这样不仅可以去掉多余的字段,还可以简化数据结构,还有一个好处是后台完全可以先写接口文档,有了二次数据处理根本不需要再次更改数据字段.大大的提高前后端工效效率.这是关于接口返回的数据的一下 想法和要求,另外返回的数据应该对应前端也页面上的每一个字段,有的字段需要直接显示,有的字段需要转义,比如状态码.还有的字段需要和其他字段一起计算显示在页面上,这些东西都要写清楚,为了不是人误会,也为了以后更好的维护项目.这些都是必须要做的.

工作的协作方式是要不断改进,前端作为一个承前启后的中心点,发挥着不可替代的作用,不重视前端的公司,其工作流程,工作效率肯定还不够好.