《重构》读后感

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