刀哥我打算重构这块代码
竖三看着这shit一般的代码,眉头紧锁,大口大口的呼气吸气,不断有轻叹声从口中传出。竖三心里暗骂:"shit,这TMD谁写的代码,完全看不懂,乱的跟乱麻一样"。不知过了多久,竖三实在忍无可忍,椅子往后一推,椅子顺势推出了一米多远,撞到墙上才停下了,竖三麻溜的站了起来,径直的走向刀哥的座位上。只见刀哥飞快的敲打着键盘。
竖三犹豫了一下,但还是打断了刀哥,说:"刀哥,有个事我想跟你说一下"。
"你说。" 刀哥放下手里的工作说。
竖三面带怒色,气不打一处来说:"我那个支付功能的代码看不懂,写的太乱了,我想把这块支付功能重构。你看行不行?"
刀哥推了推眼镜,看着这个孩子,仿佛看到了当年的自己。然后镇定地说:"嗯嗯,想法很好,但不是时候。"
"什么是时候呢?" 竖三紧追不舍的说。
"首先我们项目是在关键的交付期,截止时间是本周五下午,现在重构没办法保证功能。其次你要知道何谓重构,为何重构,还要知道重构的一些手法等等。" 刀哥不紧不慢地说。
竖三这一听心想意思是刀哥又要给我上课了,每次上课我都是云山雾绕,糊里糊涂,听了跟吃安眠药一样,不,比安眠药还管用。一回想我这不听,刀哥也不让我对代码动刀子呀,于是勉为其难的说:"刀哥,你简单跟我讲讲吧。"
"可以"刀哥说。
何谓重构
重构是对软件内部结构的一种调整,目的是在不改变软件外在行为的前提下,提高其可理解性,降低其修改的成本 。
这里有两层意思:
-
不改变软件外在的行为
-
改进代码的结构,提高代码的可读性,提高代码的扩展性,降低维护成本,这也是重构的原因
何时重构
-
添加新功能时,现有的代码无法轻松的添加新功能,我们通过重构方面地添加新功能
-
修复bug时,假如我们没法一眼看到bug的原因,或者说需要调试很久才能找到bug的根本,基本上说明代码不够清晰了,此时可以通过重构让代码更清晰。
-
在复审代码时。公司要求的审核代码的时间时,发现问题及时重构。如果公司没有要求代码审核,可以自己代码审核,比如每周固定时间,或者项目阶段性交付以后,通过复审自己的代码,发现不合理的地方,及时纠正。
何时不该重构
比起知道何时重构,何时不该重构同样重要。
-
现有代码不能正常工作,大部分功能无法使用,说明我们可以废弃现有代码,另起炉灶了。
-
项目接近Deadline不该重构,一旦重构可能会导致项目延期。这也说明一个问题,应该早点重构的。
重构的难题
数据库
-
大多数商用程序都与它们背后的数据库耦合在一起,导致了数据结构难以修改。
-
数据迁移,非常小心地将系统分层,将数据结构和对象模型间的一类降至最低,但数据库结构的改变还是会让人不得不迁移所有的数据。
修改接口
-
对于未发布的接口 如果接口的调用者都在自己的控制下,修改接口不会造成影响
-
已发布的接口 接口已经发布了,那么就需要维护新旧接口,保证调用者正常运行,对于旧接口可以通过新接口来实现。
所以注意不要过早发布接口。
难以通过重构手法完成设计的改动
考虑候选设计方案时,想想将某个方案改为另一设计的难度有多大?如果看上去简短,就不必担心选择是否得当,就可以先简单实现。如果预先不到看不到重构方法,就需要在设计上投入更多力气。
总结
-
何谓重构(what) :在不改变代码外在行为的前提下,对代码做出修改,以改进程序的内部结构。
-
为何重构(why):改进代码的结构,提高代码的可读性,提高代码的扩展性,降低维护成本。
-
何时重构(when):添加新功能时,修复bug时,在复审代码时。
-
何时不该重构:现有代码大部分功能不能正常工作,项目接近Deadline。
-
重构的难点(Problem):数据库相关的代码改动,修改对外接口,框架设计相对难以改动。
竖三听后对重构有了一定的概念性的了解,但是呢,还是云山雾绕,说:"刀哥,我想消化一下。"
"OK,你先消化一下,一次不讲那么多了,免得你消化不良。改天我再跟你说说如何识别坏代码。" 刀哥说。
"OK。" 竖三说。
扫码关注公众号,查看更多内容。