w3ctech

我的前端流程

之前写过一篇 我的前端切图过程 但由于环境和变更和业务的变更,我又在之前的流程上细化了下,以下只是我对我工作流程的总结,不一定适合其他开发者和其他项目~

当然这些前提是公司已经有自己的UE规范,前端代码规范,数据规范,交互规范

需求评审

每个项目初期都会进行评审,且在此之前都会跟参会人员发送一个"市场需求文档"(以下简称MRD),前端开发(以下简称FE)在拿到该文档后要对该文档里的内容进行审查,并把有疑惑的地方标记下来,以方便开发的时候询问并确认。

一般评审会是由PM发起,由FE,UE,RD参与,一般这个时候已经有UE的初稿,并会附加到MRD里以方便FE查看,FE在评审会上一般需要确认以下:

  • UE页面中显示字段的类型,是否有可选、必选,如果为可选就会有空的时候存在,那么UE界面如何展示
  • UE页面中是否有超出长度的字段,是前端截断还是自适应
  • 是否有"不展现"的状态,比如未达到某种条件不出现的逻辑
  • 页面是否有一些特殊的点击区域,比如移动端的点击区域要扩大
  • 跟RD对接数据接入的方式,接下来要确定的沟通数据结构和字段名
  • 自己的排期

当然,也正如@rambo说的,这些部分应该是UE考虑的范畴,但如果真到FE这边了,自己必须得处理这些,不然线上的bug机率要高很多~

如果会上没有搞清楚的事情一定记下来,待会后单独找PM确认,一定保证在开发之前把所有的逻辑明确,这样才能提高效率。

一般情况下我习惯在开发之前把我所有明确的逻辑以图文的形式发给PM查看,比如有页面各个状态的描述、出现条件、UE展现,以色块来区分的点击区域等。且这个邮件以后还有大用。

FE开发

明确了需求,知道了逻辑,有了数据格式,开发就略爽了,只需要按照FE的规范,把功能写出来就OK了

但要注意的是,一定要考虑到之前的各个状态,比如截断,判断等

自测

当自己的代码写完后首先要保证兼容性,这个就不多说了,其他就是逻辑测试,这里要说明的一点就是:RD给的测试数据格式大多都是一种,比如给的5条,但逻辑上又是超出5条才分页,如果按测试数据那么一辈子也测不到分页,乍办呢?

答:自己模拟数据~

我通常是为了测试不同的展现策略,自己要去模拟可展现这些页面状态的数据,我一般是在url中加GET参数完成,比如:

  • ?status=:默认状态
  • ?status=1:每页5条,分3页
  • ?status=2:单个tab导航
  • ?status=3:第1,3,5行的名称超出
  • ?status=4:第2,4,5行的时间为空
  • ?status=5:3+4
  • ?status=6:链接不可点
  • ?status=7:设置数据为100条,测试前端展现
  • ?status=8:设置数字为0条,测试前端展现
  • ...

ps:以上只是一些展现的模拟,不能说明什么~

注意的是,这里的模拟数据一定要加注释,且在上线前一定删除,并且这些测试代码通常放在逻辑处理前的某一块,要做到删除这一块对整体代码无影响、不被其他正式代码所依赖

当然可能还会涉及到一些别的测试,比如速度测试,压力测试,规范测试等,这些跟据所要求的流程走即可。

当这些自测都通过后,接下来的任务就比较轻松了,这时候不妨冲杯咖啡,听会悠扬的《夜的钢琴曲》,然后静静的坐会,不要问我谁是静静~

刚才@rambo也说过,这样的测试应该是QA来做,但问题是就我目前的接触QA是不管代码的,数据满足不了这些条件是不展现状态的,当然这跟所在公司有关吧。

代码方面的可以写单元测试完成,但这些展现类状态就目前我的认知范围还得靠这种方式解决,如果你能更好的解决这一环节,一定要与我联系,我请你吃饭~

UE,PM页面确认

上面曾说过我会在逻辑确认后发一个逻辑确认的邮件,这时候邮件的作用就来了。因为每一个逻辑条件可能就是一种UE展现,这时候我会对那封邮件进行编辑,所把我自测里的测试url附加上,这时候这个编辑后的邮件就成了展现确认,里面包括了:逻辑的描述和展现条件、最新确认后的UE界面截图、该逻辑完成后的url,当然如果是手机端项目,我通常会再加上一个二维码(可以直接扫打开目标页面)。当然里面也会有一些没有图的逻辑。

把展现确认的邮件发给PM,UE,我会跟进他们的反馈,是否有逻辑bug,是否有不是UE期望的效果。收到反馈后,评测这个反馈的问题,如果可以fix,直接fix并标记,如果为新需求,则评估排期并加以说明。整体解决完反馈后回复邮件,重复整个过程直到PM,UE都说"OK"为止。

通常只要"评审会“考虑的"周全",这一步是相当快的。

QA测

整理一下PM&UE在展现确认里的反馈,现结合展现确认的邮件,发送给QA妹妹(通常是妹妹吧),并附带上PM的MRD,这里就满足QA需要的:

  • 有页面逻辑描述
  • 有页面各个状态的预期展现图
  • 有页面各个状态的url
  • 有PM,UE的确认邮件

当然QA测试的可能就多了,什么多平台,多浏览器,夜间模式,各种网络适配,各种链接测试,展现日志测试,点击日志测试,报错日志,noscriptnocookie

其实我只是想"静静"的让QA妹子测试。

这里FE做的其实只是fix bug了,直到QA说"OK"为止。

上线 & 回归

上线就走上线流程即可,完成后一定要在线上回归一下自己的页面。

这时候再静静吧,因为新的一轮战斗即将发起~ 兄弟们,冲啊~


其实还是要多跟工作中的前辈沟通,多跟项目组的同学沟通,这里也说下,我们的PM真的很棒~

由于涉及到了内部数据,我就不插图了,当然如果你在流程上有什么问题,或者有什么见解,我想说:大神,请联系我~

ps: 我常活跃与北京海淀西二旗

w3ctech微信

扫码关注w3ctech微信公众号

共收到2条回复

  • 评审会真的是太必要了,而且前端是要参与的,这样可以完全避免一些不合理的问题,或者PM和开发都想不到的问题。

    回复此楼
  • @BenFei [zan]

    回复此楼