<<大话重构>>读后感

看了范钢先生编撰的<<大话重构>>,有种推开另一种窗子的感觉.

 

首先是范先生,用的是尽可以平和且带诙谐的语气来进行描述,以及对其对重构概念的重复,并且对于一引起重要的概念都总是重复,重复,又重复一遍,然后呢作为读者的我还不感觉到厌烦,更是感觉其对于重点的良苦用心.我的收获特别简单,也有下一步要补缺的地方.

 

第一点:真正是重构不要"贪多嚼不烂",想自己可以一下子化腐朽为神奇.而应该是立足于现实,逐步,渐进的进行更改. 最为实际就是立足于现有的需求而去重构,而不是把已经不堪直视的系统中再塞进去一团团代码.

第二点:也不要有畏难情绪,做到重构的过程,贯穿于程序员的所有工作中.

第三点:不要怕犯错, 要用好的测试过程来保证测试的完整性.这个说来容易,对于从没做过测试用例的人来说,有点 晕菜.

第四点:立足于需求,运用"两顶帽子"方式来重构,这个是最为实际的.(先在现有系统中,对于相应节点进行重构,并且能通过系统的测试没有问题, 再去重构的基础上添加自己的扩展.

 

第五点,我也是想真正的说下在书中我学到的重构步骤:

         分解大函数为多个小函数,把小函数分别放到外部类中,再来调用,这时也就实现了分解全能类,

这个时候,我以前就自己满足了,其实,不行,这才刚刚开始两步.

     接下来要做的事情是:提高代码的复用率(用自己拆解出来的小类,一步步减轻以前用Ctrl+C V大法造成的后遗症),这个步骤,使我们之前的做的工作更有成熟感,当然也要根据现实的需求来做,不一定一次做完整个系统.

     下一步工作就是,在我们更改替换代码的重构过程中,去着重注意一些重点的"可扩展点", 这个好像就是对设计模式用的也比较多一些,主要是利用配置文件等对if ... else 进行扩展. 不要乱用,不然代码的复杂度就大大提升了.

      再把我们自己整理的类和业务逻辑进行分析,减少类之间的依赖关系的数量.并且会有一个好的逻辑结构(这里面实际用了好几种设计方式来使我对这些设计模式的用途有了,更好的理解.),更进一步,就是分层了,但这个领域,我承认我在照本宣科,没什么大的感想.

 

我真的对测试这块很模糊,并且范先生一直希望是在开发过程(不是维护)就能做到  测试驱动模型.想想自己又明白了,我好像知道下一步要做什么了.怎么说测试,无论手动和自动也要详细的学习和应用一下,这不是理论,而是我的产品的"保险索".