一个需求变更的历史，你的设计是啥？

需求

根据用户的贡献值计算pab（支付给用户的现金）

---

 

用户信息包括

userid,classid,bu3,bu5,bu7,newimei（bu3~bu7，newimei都是某种贡献值）

---

最初的需求

pab1 = newimei * 0.8 /1.3

pab = min(pab1,bu7)

---

 

第1 次提出的 需求变更

 

当classid = 300时

 

10天内

pab1 =  bu5

pab = min(pab1,bu7)

 

10天后

pab1 = newimei * 0.8 /1.3

pab = min(pab1,bu7)

---

 

第2 次提出的 需求 变更

 

当用户userid=2000

 

pab1 = newimei * 0.8 /1.5

pab = min(pab1,bu7)

 

---

第3 次提出的 需求 变更

 

当classid = 300时

 

10天内

pab1 =  bu3

pab = min(pab1,bu7)

 

10天后

pab1 = newimei * 0.8 /1.3

pab = min(pab1,bu7)

 

因为和第2版需求很像不得标红以示区别

---

第4 次提出的 需求 变更

 

min参数变更为(注意：涉及全部的userid,classid)

min(pab1,bu5)

 

 

---

由于鄙人脑子不太够用，处理逻辑经常会拉东西，老大把这个任务交给我同事去做了，结果经常被业务人员隔三岔五的找一回，相当的郁闷，我本着人之将死其言也善的精神，给他讲了一下，通常的处理方式：

1，构造可测试接口

2，根据测试用例

     用例分为一般，UC书旗（含不同日期范围）。特定kyd,错误数据几类，这些输入都能处理的话，程序还是可靠地

---

这哥们的代码是酱紫的

 1 if(classid == 300) //uc书旗
 2 {
 3     pab1 = imei * 0.8 /price
 4     if(在15~20天内)
 5     {
 6         pab = ...
 7     }
 8     else if(在10~15天内)
 9     {
10                 pab = ...
11     }
12     else if(在10天内)
13     {
14         pab = ...
15     }
16     else
17     {
18         //这哥们就不算pab了！实际上我也这里犯过错
19         other code
20     }
21 }
22 else
23 {
24     if(kyd == 2000)
25     {
26         //特例处理
27         pab = ...    
28     }
29     else
30     {
31         //一般处理
32         pab = ...
33     }
34 }
35 
36 #update database
37 update data set pab=pab,pab1=pab1 where ...