代码评审重构案例讲解

标签：

来源：p2p系统repayCalc.cs，本代码可能参考自线下系统

一 函数语言使用问题

1）Backdate日期类型改为DateTime，则可以不用字符串拼接

2）还款日计算错误（1个月 !=  30天）

3）面向对象编程，而不是都通过函数计算

4）构造函数 替代 字符串拼接，字符串拼接和类型转换耗费CPU

5）冗余代码删除，错误情况：第一个还款日晚于借款结束日期，也不可能是按月还款了，应该在UI里面、或者函数开头处理掉，不应该在算法内部

5）类型重构，减少类型转换，删除无用中间变量

同时enddate变量属于重新定义，去掉

二 对象定义的简单方式

三 计算错误

对“每期归还本金”进行四舍五入之后，剩余本金发生变化，通过“0.004”这种方式是错误的。

移入循环，算法改成：

1）本次归还本金＝剩余本金／剩余期数

2）本次归还本金四舍五入

3）修改剩余本金、剩余期数

四 重复代码消除

1.分析

代码主体分成2块，

第一块是实际计息日等于还贷日（5日计息，5日还贷）

第二块是实际计息日不等于还贷日（5日计息，10日还贷，中间不免息。。5日计息，3日还贷，中间不免息）

这两块通过if else控制，内里充斥无数重复代码

比如以下，导致代码数量激增

2. 数据错误在开头就应该处理好，这样能尽早给出提示， 减少函数内部执行时间

重复代码提取之后，与外面类似代码合并

3.处理算头也算尾需求，原先代码两个问题：

a if else代码块分别都有计算，重复

b 只处理了实际借款天数，没有处理还款日，算头的情况，还款日需要提前一天

［修改计息日为实际计息日即可］

原先代码：

修改后代码：

五 计息日!=还贷日时，第一期利息计算错误

六 业务场景和思路问题

1）首先还贷日应该根据放款日自动生成

2）即使是如下两种情况

a)第一块是实际计息日等于还贷日（5日计息，5日还贷）

b)第二块是实际计息日不等于还贷日（5日计息，10日还贷，中间不免息。。5日计息，3日还贷，中间不免息）

在实际实现的时候， if else也应该调换，因为第一块是第二块的简化情况

解决完第一期，修改初始情况，中间期数算法等于第一块，然后剩下最后一期，最后一期和第一期算法相同。

 3）如果遵守第一个情况，那么第二种的复杂情况不会产生。

 删除if语句块

七 借款周期计算问题

1) 天数／每月天数(实际天数，和固定为30天)

2) 根据借款月数转换

 八 重构为策略模式

具体模式介绍：http://www.cnblogs.com/promise-7/archive/2012/05/29/2524357.html

策略又称做政策（Policy）模式【GOF95】。下面是一个示意性的策略模式结构图：

这个模式涉及到三个角色：

• 环境（Context）角色：持有一个Strategy类的引用。
• 抽象策略（Strategy）角色：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。
• 具体策略（ConcreteStrategy）角色：包装了相关的算法或行为。

1）目前的结构是这样的

一个类有很多不同的算法函数

2）我们需要重构成

一个抽象类，各种算法继承这个抽象类，实现类通过实例化抽象类使用具体的算法

a)定义需要被继承的类

b)定义继承上述类的算法

c)如下代码重构到Calc()方法内

重构后如下，为什么注释掉isInt，isInt的现实意义是付款方便，如果是为了付款方便，那么应该本金和利息相加后取整

调用处这么写就可以了

RepaymentPlanCalc rPlanCalc = new AverageCapital(myRateCalc.Borrowsum, totalqishu, myRateCalc.Borrowrate, time1);
backlist = rPlanCalc.Calc();

代码评审重构案例讲解

标签：

原文地址：http://www.cnblogs.com/mspeer/p/5756813.html