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

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

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

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

 

一丶重构的时机

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

　　但是随着时间的流失，不只没有重构好，并且该改的逻辑也没有改好，我很郁闷，为何会这样呢？因而开始了沉思 - 重构的时机应该是何时？

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

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

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

　　当快要接近完成的时候，再来看看之前的代码，由于从如今的眼光看之前写的，总会有新的想法，若是有，赶忙实施，写出高质量代码。

　　因此重构的时机要本身掌握好，其实有几点能够代表你须要重构：

　　1.冗余，重复代码太多；

　　2.逻辑层次不清晰，变量命名本身都搞不清楚了；

　　3.类，方法各个层次之间很混乱；

　　4.没法进行有效的扩展；

　　5.健壮性太差

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

 

二丶重构的一些技巧

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

　　1.去重，提取共用方法

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

　　2.抽象

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

　　　　其实最重要的是你要深入理解你的业务，而且抽取他们共同的部分，以及经过虚方法来实现一个方法的不一样操做

　　3.抽象工厂

　　　　抽象工厂又能够分为：单例工厂和多实例工厂

　　4.配置文件

　　　　自定义配置文件，能够更有效的控制不一样方式作不一样的事

　　5.灵活运用Attribute

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

　　7.反射

　　好了，就这些，还有不少没学习了，继续加油......

 

以同步至：我的文章目录索引