危机与重构唐帝国读后感细选(16)

开篇作者并没有像常见的那样为＂重构＂正名溯源，而是操刀剖析了一个出租影片程序的案例。原来的代码能够满足当前需求的功能，但是面临着眼前需要增加新功能打印html格式，日后可能变更影片分类的长远需求。在变更前，作者对于最初的程序画出了问号。然后按照每次谨慎地移动一小步，频繁地测试的原则，对原来的代码实施重构。小步挪动以后，擦亮了窗户，对于程序的结构看得更远了，继续微调。终于在最后解决了该程序面临的问题，增加了程序的灵活性，但是也使得代码变得更加复杂了，减小了函数的功能粒度。似乎是微不足道的量变，产生了质变。代码在没有改头换面的前提下进行了脱胎换骨。
第二章作者开始步入常规，解释关于refactoring有关的what（重构是什么），why（为什么要重构），when（什么时候进行重构），how （如何提出重沟）问题。作者也解释了重构面临的难题。我感兴趣的是重构和设计，性能比较的两节。通过对oop的学习，我逐渐理解和接受了项目逐步培养，成长的观念。原来我一直按照瀑布式开发，在项目后期总出现一些当初设计想象不到的情况，开始我总归结于自己经验不足，需求分析做的不够深入细致。接触到xp 和重构以后，心中有一种豁然开朗的感觉。但是我想重构与瀑布式并不是截然对立的，而是项目开发过程中两个侧面。在我所参与的动辄上百人参与，软硬同吃的项目中完全采用xp是不可思议的，两者必须结合使用。作者对于程序性能的问题的观点也让我耳目一新，他提出只有在需要的时候才着眼性能，而且通过测试而不是事前分析的方式寻找性能问题的瓶颈在那里。
接着作者用22种代码中的坏味道描绘了需要重构的种种征兆。这一章和第6章一样，我读得很＂流＂，感觉内容很容易理解，但是读完以后脑海中印象却不深刻。尤其是具体的重构方法，有时候感觉作者挪动的步伐太小了，太谨慎了。也许像侯捷在序言中所说的，是日后计算机自动完成的步骤；也许是我看别人做事自己站着说话不腰疼，以后跌了大跟头才能知道其中的真意吧。