重构,一小步一小步来

爸爸:”你要好好学习”

爸爸:”你不要早恋”

爸爸:”你要****,不要*****”

终于有一天,我忍不住问

“当年我爷爷这样说过你吗?”

爸爸:”嗯,说过”

“你听他的话了吗?”

“没有”爸爸回答.

有些路,走过之后,才知道那是弯路,哪怕以前别人告诉过你很多遍.

重构我以前在书上看到过,有些原则要遵循.以为记住了,但是实践的时候却抛之不顾,现在,重构要遵循多少我不知道,但是我忘不了一条,重构要一步一步来,每次一小步,比一次大修改在编码上费时间,在调试时要省出好几倍的时间.

1.一小步改动,编译,让编译器帮你查找相关联的代码

          第一个项目是SD卡及文件系统的优化.当时采用的是FAT32文件系统,不知道当初的设计者出于何种考虑,整个系统没有考虑缓存一些经常使用的扇区.FAT最常用的是操作是寻找FAT表,目录项,原系统每次读取一个扇区,下次看下扇区是否有用没有则重新读取.我想到的第一个修改就是缓冲部分常用的扇区,毕竟内存很充足.另外要说下,那个读SD卡采用的是IO脚模拟SD时序,可以想象读取一个扇区会有多慢.

当时就是一个新手,嘛经验没有,明确目的后就开始修改,.简单的分模块修改还是知道的,先把SD卡由单块写改为多块写,测试没问题后修改FAT32.当时是一下子把所有的原先单扇区读写的地方全改成了缓冲操作,先在缓冲区找,找不到更新缓冲区.然后编译,无穷多个错误.我也纳闷,我当时怎么就没一直没编译,非得等到全改完才编译.然后大家可以想到,改动是在是太大了,别说出效果,就是想编译过去都难,花了好久才编译过去,调试更是困难,几乎没有阶段性标志.不过加班加点总算按期完成.

2.重构,是在理解原实现的基础上进行的,分析其过时和不妥的地方加一修改,而不是推到重来.但是,通过读代码,原来的的实现你能理解多少?

             读原来的代码,把握了原来实现的大致思路在细节上总感觉一些代码可有可无,在重构时顺便就去除了逻辑上无用的代码,比如一个毫不相关的循环加法运算.但是新的代码罢工了.对于PC应用好说,对于嵌入式底层一般有时序的要求.没错,上一个程序员将循环做加法当作短暂延时来满足时序要求(可能当时他也是调试时无意发现这样可以工作就加上了),你去掉了,看是逻辑无关紧要,但是时序却全变了.然后系统工作了,避免不了了是bug.在你调试的过程中,慢慢发现原来那些去除的一些感觉没用的代码就是用来解决这种难得一遇的bug的.很多代码很突兀,在没有注释的情况下,若不是亲手调试,很难意识到他们的作用.没办法,对比老工程,回复那些代码,不过能改的就改的意思明显点,实在没办法的加上点注释,为后来者省点事.

对于那些突兀的又看不出作用的代码,我学乖了,先在老工程里注释掉,跑跑看看,没什么情况,在去掉.但是,很多代码属于历史遗留,去掉也没问题,每次都这样,很慢的.

3  这是我自己的经验,不知道对不对,是在一小步一小步改动的基础上自己的理解,就是在重构时,尤其是代码框架重构时,尽量用原来的代码,甚至使用需要重构的高层接口,来使框架运行起来.也许全局变量满天飞,也许代码很糟糕,先不去管他.先让框架能够跑起来,尽量让每一次的改变都工作起来.

看到一篇重构的文章,有点意思,这是传送门

http://coolshell.cn/articles/5201.html