学习之路四十一丶简论重构

四月份的最后一天,写点心得,记录一下。

这个月一直忙着开发一个基于Win32 API的程序,大量运用了句柄等很多API的知识。

尤其随着代码量越来越大,逻辑越来越复杂,代码的清晰,健壮,扩展性成了一个需要重视的问题,也就是要适时的重构了。

 

一丶重构的时机

  上个星期在修改一块重大逻辑的时候,需要修改很多代码,当时我犯了一个错误,一开始想了一个思路,但一上来没写多少就开始想着重构代码,目的是使其代码清晰以及可扩展。

  可是随着时间的流失,不仅没有重构好,而且该改的逻辑也没有改好,我很郁闷,为什么会这样呢?于是开始了沉思 - 重构的时机应该是什么时候?

  重构的时机要把握的恰到好处,太早缺乏代码之间的连贯性,因为你代码都没有写好,就想着开始重构了,那可不好;太晚代码写好了,逻辑也通了,但是改起来特别费力,是牵一发而动全身,说不定还改出了更多问题呢,需要花更多的时间去修改代码以及 fix bug。

  所以重构的时机因人而异,因你的能力,因你的业务流程熟悉度,不过我选择的时机是中间靠前一点

  因为这个时候你已经写了将近一半的代码,业务逻辑也已经实现了一半了,那么是否出现代码冗余,阅读性差,抽象程度差的问题,如果有的话就要想想该怎么重构了,如果没有继续往下写,保持好状态。

  当快要接近完成的时候,再来看看以前的代码,因为从现在的眼光看以前写的,总会有新的想法,如果有,赶紧实施,写出高质量代码。

  所以重构的时机要自己掌握好,其实有几点可以表明你需要重构:

  1.冗余,重复代码太多;

  2.逻辑层次不清晰,变量命名自己都搞不清楚了;

  3.类,方法各个层次之间很混乱;

  4.无法进行有效的扩展;

  5.健壮性太差

  所以在遇到上面一些问题之后,就要思考需要用哪些重构技巧来改善代码质量了,这个需要积累,加油。

 

二丶重构的一些技巧

  这里就写一些我重构用的方法:

  1.去重,提取共用方法

    记得写过一个去除重复的try-catch的代码,用到了委托以及反射来减少重复代码

  2.抽象

    接口,继承,虚方法,抽象类。

    其实最重要的是你要深刻理解你的业务,并且抽取他们共同的部分,以及通过虚方法来实现一个方法的不同操作

  3.抽象工厂

    抽象工厂又可以分为:单例工厂和多实例工厂

  4.配置文件

    自定义配置文件,可以更有效的控制不同方式做不同的事

  5.灵活运用Attribute

  6.取更有意义的变量,属性,方法,类的名称,长一点没有什么大碍

  7.反射

  好了,就这些,还有很多没学习了,继续加油......

 

以同步至:个人文章目录索引 

posted @ 2014-04-30 22:19  TimYang  阅读(314)  评论(1编辑  收藏