【公文】《重构》读后感.docxVIP

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