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