重构诉讼体制读后感收集(8)

第二章作者开始步入常规，解释关于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)的格式进行。这么多模式，很难记忆完全，也没有必要。我想如果理解了重构的概念和原理，具体的模式可以像字典一样平时多翻翻，多琢磨。具体做的时候没有必要非要搞清楚自己使用的是哪一种模式，然后严格按照书上的步骤照猫画虎。无招胜有招，把重构融入到自己平时的编程过程中才是真正掌握了。