在代码重构中蜕变

  这几天,要对我半年前写的代码进行一些整理工作,在看代码时发现当时有很多地方写得不够好,俗称的有“坏味道”,呵呵,重构,必须的。

  几年前通读过《重构,改善既有代码的设计》一书,虽然对各种重构模式或方法记忆有限,但精髓还是记住了:改代码而不改变软件的外在表现,循序渐进。

  其实,重构是一个开发人员的基本工作内容,是在每天的开发过程中都要用到的。离开了重构和测试,代码质量是难有保障的。有人会说没有用到重构,其实最简单的例子,当你发现一个类中有几处用到了相同的代码,你把这几行代码提取到了一个私有函数中以供复用,这就是一次重构。所以说,别跟人炫耀你会重构,这是基本功。

  好久没更新博客了,借此说说我的一点心得吧。

  1.目的明确。代码是一种平衡的产物,很多地方都在保持着某种平衡,有功能与性能的平衡,有可靠性与可维护性的平衡等等,每一次动手,都要有一个目标,是想改进局部代码,还是想改进类结构,只有针对不同的目的才能实施不同的方法。

  2.评估影响。改动前,最好能有个预估,对可能产生的影响做到心中有数,以免引起不必要的后果。在“坏味道”的代码中是很有可能牵一发而动全身的,要注意安全。如果只是对类的私有成员的改动,那通常影响的范围有限,如果涉及到对公有成员或保护成员的改动,那就要注意了,简单的评估方式是充分利用IDE的搜索、引用等功能,把引用过此成员的代码行全部找出来,看看影响的范围有多广,如果有些代码不在你的控制之内,那就要慎重考虑这个重构了。

  3.慎改结构。设计人员或架构师在定义类结构的时候一定有他的综合考虑,在没有充分理解之前,请慎重吧。不要拿设计模式去套现有的结构,设计模式是个指导,如果学完设计模式还在硬用来套用,那这种僵化的思维还不如不学的好。所以,当想要做这样的重构时,请与你的设计师、架构师或有经验的同事协作,除非你自己就是设计师。

  4.小步伐前进。每次改动尽量小,这样可以把影响限制到小范围。就像一个公式一样,如果同时改变其中的几个变量,那很难说是哪一个影响了结果,但如果一次只改变其中的一个,就可以确认其对结果的影响。尤其是当代码已经完成了用户需求,这时的重构只是为了让代码更好,切忌不要影响到已经得到用户确认的外在表现。

  5.测试。无论你的开发是否是测试驱动,在重构时测试是保证代码正确的必要手段。修改-编译-测试,重复这个过程,直到达到目的。

  当你花了几分钟或者几个礼拜,已经让代码大为清爽的时候,回过头来对比曾经的“坏味道”,我想,你会喜欢上代码的,重构会发生在你写下一行代码的时刻,变成了编码能力了。

  少一行代码,就少一分出错的可能,别心疼你删除掉的代码,虽然那是你的心血,但那已经是历史,在重构代码中蜕变已经完成。

it知识库在代码重构中蜕变,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。