对重构的理解

重构，我的理解就是整理代码。记得以前有人跟我说“做软件，一定要对自己的东西尽量最求完美”。我想他这句话应该和重构有点关系吧。

记得我刚开始写程序的时候，什么都不会，有点乱写的意思。想到哪儿就写到哪儿，经常是写了一周的代码，自己都不知道自己写些什么。运行中出现问题，自己都头疼去看源代码。那时候，对oop不熟悉，也懒得去修改，这大概是造成这种局面的原因了。

 

后来有时间了，看看书，知道了什么是类、对象，继承，重载，覆盖。什么是抽象函数、虚函数。然后再回头看看自己的代码，觉得不足的地方太多了。

找了个自己觉得写得还行的程序，回头修改，把学到的东西都用上了，那感觉：爽。那时候都弄得我神经了，走路睡觉都想着怎么写程序。把1000多行代码改成几十行代码，那感觉别提多美了。

以前，经常听别人讲什么设计模式，不懂。自己硬着头皮看书，还是不懂。现在通过重构代码，终于明白了：设计没有模式，我想到了，用到了，模式就来了。所以我到现在还是觉得模式是看书看不来的。

在后来知道了什么是反射，代码修改起来就更方便了。不过这玩意儿不敢多用。就像肉不敢多吃怕香着一样，主要是担心这玩意的性能。

修改代码的时候，会有这样一种情况。忽然有了一种新想法，觉得合理，但是觉得如果这样一改代码改动就大了，怕麻烦，而且还不知道自己的想发到行得通行不通。而且，真的实现了，性能怎么样还不知道呢？这时候就想打退堂鼓。我有很多这样的时候，不过很多时候我坚持改了，多数修改成功了，看着代码量减少，功能不变，心里美极了。我觉得这时候应该坚持，即使失败，也有心得，知道为什么不行。再说，代码这东西又不是建筑。路走不通最多回到当初呗。

后来试着自己写了一个代码生成器，并根据代码生成器搭建了一个框架。开始是三层，后来也就不好说几层了，因为被我重构的面目全非了，但是我觉得比开始时好用了。

在重构这个框架的时候想的就更多了，是不是利于测试，是不是容易让别人用起来好用，是不是让别人容易理解，是不是能降低用的人的出错的概率等。而且有时间的时候去看看structs,hibernate,dnn,cs的一些东西，他山之石，可以工玉。

现在，我有时间的时候就会去重构自己的代码，这是一项很舒服的事。

 

我们写完代码后要回过头来好好整理一下我们写的代码。包括
整理代码，添加注释，修改不合适的变量名，去除多余代码，

抽象共同的代码，
封装成公用类，
应用设计模式，
降低代码的耦合度，
甚至对业务逻辑进行抽象。

如果没有重构，最后的代码会牵一发而动全身。连自己都怕修改。

其实，许多的设计模式都是重构出来的。设计本来没有模式，我们重构的时候需要了，就出来模式。所以说重构自己的代码，就是学习，就是提高自己的技艺。
而且重构后的代码比原来的正确，也更利于测试。在开发中如果不怎么重视测试的，通过重构减少bug是一个很好的途径。