说明:经验是个好东西,希望你也能拥有,如果这就是经验,我想我也get到了一点点
其实开发一个模块或者实现一个功能.需求分析时间应该占到30%左右.下面以一个看似非常简单模块为例.
这是原有的基础,看似就是简单加一个小功能,判断是否显示超出范围调整
一:仔细分析需求后应该会有一些疑问
1:超出调整范围是否只是在我们页面进行显示?还是需要回传数据?
1.1 hr不需要再传递额外的字段,我们只要根据目前字段就可以实现功能
1.2 "是否越级晋升"的判断标准是什么?以下三个哪个属于越级晋升?
P2---P3? P2---P5? P2--M2?
1.3 "上次调整时间"对应什么字段?是页面上"内部调转时间"吗?
如果是,那么这个字段会不会有空值?如果初始值=="入职时间"的话会轻松很多,不然以后做判断的时候会稍微麻烦些
另外"发起时间"和"内部调转时间"和"上次调整时间"以及"入职时间"的关系
1.4 "晋升的级别在M2以上或者P7以下，距上次调整时间或入职时间小于6个月" 这么长的字段,在web端,特别是手机端,对整体页面布局都会产生影响的.
1.5 字段确认此处是"M2以上"还是"M2以下"?根据上下文分析,应该是"M2以下".
1.6 我们就假设原有的逻辑和数据都是正确,不会出现,明明薪资调整了,"薪资是否调整"字段还出现"否"的情况;也不会出现"上次调整时间"<"入职时间"这种低级bug
2:"手动选时间" 我们是否需要回传过去?
"入职时间"也能随意调整.比如说判断的上次调整时间2017-10-1 由于晋升级别小于6个月,所以显示"超出调整范围".如果手动改成"2005-10-1"号,那么会有什么影响?如果该员工是"2015-10-1"才入职的.那么这个时间是改的入职时间还是上次调整时间?如果公司是2010年才成立呢?而且这个"上次调整时间"是指"上次晋升的调整时间"?还是指"上次调薪的调整时间",或是不区分
从第一阶段的分析来看,我们不仅要提出对需求的疑惑的地方,还要对设计指出不足,有时候还不能简简单单的把问题抛出来,还要自己试着去寻找答案,例如1.3这个问题,我们可以从系统中原有数据,分析归纳
二 敲代码前的草稿
我们需要大致打这样一个草稿,这个比较简单.所以在摸清需求的情况下可以自行开发,如果比较复杂,需要跟开发经理商量,看看思路是否跑偏,使用技术是否合理,
三:要预判技术难点.以我个人的意见,可能这个习惯未必利于对技术的发展.系统中有的能抄就抄,自己设计第一比较慢,而且实现起来坑比较多,也不利于后期其他人的维护
3.1 手动选时间,需要引入控件或者jQuery插件吗?直接使用我们系统中的日期控件会不会有问题?是否需要回传数据?如何回传数据?有类似的例子吗?
3.2 js如何对两个时间格式的字符串做差?
四:为测试人员提供一些测试用例.因为这段代码是我们写的,哪些薄弱的地方用可能出问题自己比较清楚,我们有义务为测试提供"抛砖引玉"的测试用例,反过来如果这些地方真的出问题对我们也是一个成长,避免下次跳入相同的坑
一些简单的测试用例
因为"调薪幅度"是我们这次开发功能的"根数据",所以要务必确保其正确性
1:发起一笔薪资不调整的单子.目的:测试判断如果"调薪幅度"不存在的时候会出现什么情况
2:发起一笔降薪超过30%的单子.目的:测试降薪出现负数的情况
3:越级晋升,但薪资不调动