《重构》读后感范文.doc

重构读后感范文 711字数：1681 网上对于这本书的评论很热闹在读java编程思想感觉有点疲倦的时候我拿起了这本书这本书作者是martinfowler而且封面上印着与设计模式齐名的经典巨著设计模式作者为本书作序超过70种行之有效的重构方法等宣传语对于这些宣传语我第一个感觉是宣传的噱头martin没有必要通过本书与设计模式的比较显示自己的身价另外由于文中常常有交叉引用可能侯捷熊节采用页页对译显得每页留白很多 开篇作者并没有像常见的那样为重构正名溯源而是操刀剖析了一个出租影片程序的案例原来的代码能够满足当前需求的功能但是面临着眼前需要增加新功能打印html格式日后可能变更影片分类的长远需求在变更前作者对于最初的程序画出了问号然后按照每次谨慎地移动一小步频繁地测试的原则对原来的代码实施重构小步挪动以后擦亮了窗户对于程序的结构看得更远了继续微调终于在最后解决了该程序面临的问题增加了程序的灵活性但是也使得代码变得更加复杂了减小了函数的功能粒度似乎是微不足道的量变产生了质变代码在没有改头换面的前提下进行了脱胎换骨 第二章作者开始步入常规解释关于refactoring有关的what（重构）why（为什么要重构）when（什么时候进行重构）how（如何提出重沟）问题作者也解释了重构面临的难题我感兴趣的是重构和设计性能比较的两节通过对oop的学习我逐渐理解和接受了项目逐步培养成长的观念原来我一直按照瀑布式开发在项目后期总出现一些当初设计想象不到的情况开始我总归结于自己经验不足需求分析做的不够深入细致接触到xp和重构以后心中有一种豁然开朗的感觉但是我想重构与瀑布式并不是截然对立的而是项目开发过程中两个侧面在我所参与的动辄上百人参与软硬同吃的项目中完全采用xp是不可思议的两者必须结合使用作者对于程序性能的问题的观点也让我耳目一新他提出只有在需要的时候才着眼性能而且通过测试而不是事前分析的方式寻找性能问题的瓶颈在那里 接着作者用22种代码中的坏味道描绘了需要重构的种种征兆这一章和第6章一样我读得很流感觉内容很容易理解但是读完以后脑海中印象却不深刻尤其是具体的重构方法有时候感觉作者挪动的步伐太小了太谨慎了也许像侯捷在序言中所说的是日后计算机自动完成的步骤；也许是我看别人做事自己站着说话不腰疼以后跌了大跟头才能知道其中的真意吧 umlclassdiagram和junit是顺利进行重构的左右双翼在第1章中的那些unl类图我认为只是对代码进行重构结果的解释并不是通过分析unl类图发现需要重构的迹象如果从项目整体或者多个类的关系入手进行重构的话uml类图可能能够负担行军路线图的重担（但是你为什么要等到这时候才进行重构呢）而junit是进行频繁测试的依仗只有实现测试的自动化才可能随时的重构作者用第4章一章的篇幅详细介绍了测试的观点junit测试构架 从名为“重新组织你的函数”的第6章开始作者详细介绍了每一种重构方法对于每种方法按照名称(name)、概要(summary)、动机（motivation）、做法(mechanics)、范例(examples)的格式进行这么多模式很难记忆完全也没有必要我想如果理解了重构的概念和原理具体的模式可以像字典一样平时多翻翻多琢磨具体做的时候没有必要非要搞清楚自己使用的是一种模式然后严格按照书上的步骤照猫画虎无招胜有招把重构融入到自己平时的编程过程中才是真正掌握了 这本书翻译得很流畅我在不知不觉中被文中生动自然的语言带到桃源深处领略别样风景至于网友常常争