重构,开始第一个案例

前言

你会发现所谓设计不再是一切动作的前提,而是在整个开发过程中逐渐浮现出来的。——Martin Flower 

没有银弹,没有放之四海而皆准的真理。

重构和自动化测试时紧密联系的,没有自动化测试,重构会步履维艰。

重构:在不盖被代码外在行为的前提下,对代码做出修改,以改进程序的内部结构。也就是在代码写好之后改进它的设计。

重构,开始第一个案例

1.1  起点

如果你发现自己需要为程序添加一个特性,而代码结构使你添加这个特性非常困难,那么先重构那个程序,使特性的添加比较容易进行,然后在添加特性。

1.2  重构的第一步

第一个步骤:为即将修改的代码建立一组可靠的测试环境。这样才能有效防止重构带来的危害。 这个测试环境首先要涵盖单元测试,集成测试,功能测试,其他,可以自动化运行所有的测试用例。

好的测试时重构的根本。

重构之前,首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验(self-checking )能力。

1.3  分解并重组

遵循《代码大全》的一些构建原则,可以得出更加优良的设计,从而减少重构的几率。但是“过度设计”也是不恰当的。所以,设计是一个迭代的过程,在迭代的过程中进行优化,重构。

重构技术系以微小的步伐修改程序。如果你犯下错误,很容易便可发现它。

任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人来容易理解的代码,才是优秀的程序员。

代码应该表现自己的目的。重构代码的过程中,将自己的理解嵌入代码。

慎用宏,而已常数变量来代替。

/* * 原始需求背景: * 网宿CDN要按月收取客户的服务费用,根据流量的大小、 * 服务的类型等,收取不同的费用,收费规则如下: * web应用:1000元/M * 流媒体应用:1000元/M*0.7 * 下载应用:1000元/M*0.5 * 月末打印报表时,要罗列每个用户每个频道的费用、客户总费用, * 还要打印该客户的重要性指数,重要性指数=网页流/100+下载流量/600; * * 需求变更场景: * 系统已经开发出来了,接下来,运维部门现在希望对系统做一点修改, * 首先,他们希望能够输出xml,这样可以被其它系统读取和处理,但是, * 这段代码根本不可能在输出xml的代码中复用report()的任何行为,唯一 * 可以做的就是重写一个xmlReport(),大量重复report()中的行为,当然, * 现在这个修改还不费劲,拷贝一份report()直接修改就是了。 * 不久,成本中心又要求修改计费规则,于是我们必须同时修改xmlReport() * 和report(),并确保其一致性,当后续还要修改的时候,复制-黏贴的问题就 * 浮现出来了,这造成了潜在的威胁。 * 再后来,客服部门希望修改服务类型和用户重要性指数的计算规则, * 但还没决定怎么改,他们设想了几种方案,这些方案会影响用户的计费规则, * 程序必须再次同时修改xmlReport()和report(),随着各种规则变得越来越复杂, * 适当的修改点越 来越难找,不犯错误的机会越来越少。 * 现在,我们运用所学的OO原则和方法开始进行改写吧。 */
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值