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

需求

根据用户的贡献值计算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,错误数据几类，这些输入都能处理的话，程序还是可靠地

---

这哥们的代码是酱紫的

if(classid == 300) //uc书旗
{
    pab1 = imei * 0.8 /price
    if(在15~20天内)
    {
        pab = ...
    }
    else if(在10~15天内)
    {
                pab = ...
    }
    else if(在10天内)
    {
        pab = ...
    }
    else
    {
        //这哥们就不算pab了！实际上我也这里犯过错
        other code
    }
}
else
{
    if(kyd == 2000)
    {
        //特例处理
        pab = ...    
    }
    else
    {
        //一般处理
        pab = ...
    }
}

#update database
update data set pab=pab,pab1=pab1 where ...