代码评审重构案例讲解

来源: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();

时间: 2024-08-02 20:20:55

代码评审重构案例讲解的相关文章

同行代码评审过程中的实践经验

声明:该文经我翻译后首次发表在伯乐在线上,不论什么形式的转载都请标明原处. 数百万年前,猿从树上下来,进化出了对生拇指,终于.变成了人类. 我们以相似的眼光来看下强制性代码评审(Code Review):好像是一种能在软件开发这块广阔的领域里将人类从兽里分离出来的东西. 只是,我有时候会从我们的团队成员里听到以下这种评论: "这个项目的代码评审根本就是浪费时间." "我没有时间做代码评审. " "我的项目公布延期了.都是由于我那懦弱的同事还没有做不论什么评

对代码评审的感想(回忆篇)

对代码评审的感想(回忆篇) 回想之前钱老板开代码评审流程的讨论会,有事没去,有些遗憾,所以谈下这个当前最fashion的话题,分享下之前对代码等评审的体验. 之前在CFT的研发氛围还是比较重视代码评审的,完成度也比较好,原因有以下几个: 业务特性.我们是的业务跟钱打交道的,所以一发生问题,损失的都是钱,所以追责很严,惩罚很重,而且罚钱一般都罚老大,所以质量上的规范容易从上往下推动,事半功倍.当然线上出现问题,往往会让QA(质量管理)追着问原因以及要求拿出改进措施,作为小兵也很烦很害怕有木有~ 严

6.我们真的做了代码评审

静态代码检查工具StyleCode. 上一章我说了设计评审和测试用例评审都是为了提升产品质量问题,后来我们又做了代码评审,但是代码评审比设计评审难搞多了,对于开发来说最在意的就是自己的代码,让别人对自己的代码指指点点,虽然是好的建议但也会让人不爽. 准备搞代码评审之前以前就尝试过,搞着搞着最后的结果只是变成一种形式而已,大家热情都不高,反而给团队增加了负面的情绪.在现在团队中由于代码质量问题,减少bug的产出,在回顾会议中团队提出可以试一下代码评审,是对这个解决办法存在担忧的.我们采用style

自动提交Git branch代码评审到Review Board系统

背景 敏捷软件开发中,越小的反馈环,意味着软件质量越容易得到保证. 作为组件团队,我们的开发任务中,往往存在一些特性涉及到几十个功能点,开发周期持续数周或数月的情况.如何在开发过程中保证软件质量,是个很重要的话题.进行有效的细粒度的代码评审,是常见的手段之一.但是这一希望在落地时,多多少少会遇到些来自方方面面的阻力: Review Board不支持Git branch的代码评审提交: Git不熟,不知道怎么生产正确的patch文件来提交到Review Board上: Review Board不会

传智播客C语言视频第二季(增加诸多C语言案例讲解,有效下载期为10.5-10.10关闭)

?? 卷 backup 的文件夹 PATH 列表卷序列号为 000000F4 D4A8:14B0J:.│  1.txt│  2.txt│  ├─1传智播客_尹成_C语言从菜鸟到高手_第一章C语言概述A│  ├─文档│  │      第1讲 C语言第一阶段.doc│  │      │  └─视频│          第1讲 C语言第一阶段.mp4│          ├─2传智播客_尹成_C语言从菜鸟到高手_第二章C语言跨平台HelloWorld-A│  ├─第10节 2.5.1-2.5.7C

使用Jquery+EasyUI 进行框架项目开发案例讲解之五 模块(菜单)管理源码分享

http://www.cnblogs.com/huyong/p/3454012.html 使用Jquery+EasyUI 进行框架项目开发案例讲解之五  模块(菜单)管理源码分享    在上四篇文章  <使用Jquery+EasyUI进行框架项目开发案例讲解之一---员工管理源码分享>  <使用Jquery+EasyUI 进行框架项目开发案例讲解之二---用户管理源码分享>  <使用Jquery+EasyUI 进行框架项目开发案例讲解之三---角色管理源码分享> <

有关memcached企业面试案例讲解

有关memcached企业面试案例讲解 1.Memcached是什么,有什么作用?    a. memcached是一个开源的.高性能的内存的缓存软件,从名称上看Mem就是内存的意思,而Cache就是缓存的意思.    b. 作用:memcached通过在事先规划好的内存空间中,临时缓存数据库中的各类数据,以达到减少业务对数据库的直接高并发访问,从而达到提升数据库的访问性能,加速网站集群动态应用服务的能力. 2.Memcached服务在企业集群架构中应用场景  (1). 作为数据库的前端缓存应用

使用Jquery+EasyUI 进行框架项目开发案例讲解之四 组织机构管理源码分享

http://www.cnblogs.com/huyong/p/3404647.html 在上三篇文章  <使用Jquery+EasyUI进行框架项目开发案例讲解之一---员工管理源码分享> <使用Jquery+EasyUI 进行框架项目开发案例讲解之二---用户管理源码分享> <使用Jquery+EasyUI 进行框架项目开发案例讲解之三---角色管理源码分享> 我们分享了使用Jquery EasyUI来进行ASP.NET项目的开发的相关方法,每一个模块都有其共用性,

团队管理中的代码评审

代码评审在软件项目管理中是经常组织的活动,通过代码评审的工作也确实给我们的团队带来很多的益处,简单谈谈代码评审的感受,你们的团队是否也在进行代码评审(Code Review)的相关工作呢? 1.为什么要组织代码评审 组织代码评审其主要目的是保障我们的代码质量和软件产品质量,其次是团队的学习提高,共同的成长.可以是两个方面的驱动,外在现实中的工作痛点和团队内在战斗力提高的驱动. (1).实际工作中的痛点:<1>.团队开发的软件质量越来越差,Bug居高不下,问题层出不穷:<2>.团队的