难以通过重构手法完成的设计改动
比如说在一个项目中，我们很难（但还是有可能）将“无安全需求情况下构造起来的系统”重构为“安全性良好的系统”。
这种情况下我的办法就是“先想象重构的情况”。考虑候选设计方案时，我会问自己：将某个设计重构为另一个设计的难度有多大？ 如果看上去很简单，我就不用担心选择是否得当，于是我就会选择最简单的设计，哪怕它不能覆盖所有潜在需求也没关系。但如果预先看不出简单的重构办法，我就会在设计上投入更多力气。
何时不该重构？
重写（而非重构）的一个清楚的讯号就是：现有代码根本不能正常工作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。记住，重构之前，代码必须起码能够在大部分情况下正常运作。
另外，如果项目自己已近最后期限，你也应该避免重构。在此时机，从重构过程中赢得的生产力只有在最后期限过后才能体现出来，而那个时候已经时不我予。
Wrad Cunningharn的看法：未完成的重构工作是“债务”。过于复杂的代码所造成的维护和扩展的额外开销，就是利息。你可以承受一定程度的利息，但如果利息太高你就会被压垮。把债务管理好是很重要的，你应该通过重构来偿还部分债务。
重构与设计
Alistair Cockburn：有了设计，我可以思考更快，但是其中充满小漏洞。
有一种观点认为：重构可以成为“预先设计”的替代品。这意思是你根本不必做任何设计，只管按照最初想法开始编码，让代码有效运作，然后再将它重构成型。极限编程的支持者极力提倡这种办法。
但这不是最有效的途径。极限编程的爱好者们也会进行预先设计。他们会使用CRC卡或类似的东西来检验各种不同的想法，然后才得到第一个可被接受的解决方案，然后才开始编码，然后才能重构。关键在于：重构改变了“预先设计”的角色。如果没有重构，就必须保证“预先设计”的正确无误，这个压力太大了。

什么是CRC卡?
CRC(Class-Responsibility-Collaborator)卡建模是一种简单且有效的面向对象的分析技术。在一个OO(面向对象)开发项目中，包括用户、分析员和开发者在建模和设计过程中经常应用CRC卡建模，使整个开发团队普遍的理解形成一致。
它由三部分组成：
1. 类(Class)
2. 职责(Responsibility)
3. 协作(Collaborator)
一个类代表许多类似的对象。而对象是系统模型化中关注的事物。他们可以是一个人、地方、事情、或任何对系统有重要性的概念。类名在CRC卡的顶部。
职责是类需要知道或做的任何事物。这些职责是类自身所知的知识，或类在执行时所知的知识。
协作是指为获取消息，或协助执行活动的其他类。在特定情形下，与指定的类按一个设想共同完成一个(或许多)步骤。协作的类顺着CRC卡的右边排列。

(上图出自http://book.csdn.net/bookfiles/116/1001163602.shtml)

在可以重构的前提下，你只需要得到一个足够合理的解决方案就够了。
如果你在预先设计时在所有有可能出现变化的地方都建立起灵活性，却在最后发现这些灵活性都毫无必要，这才是最大的失败。你知道，这其中肯定有些灵活性的确派不上用场，但你却无法预测到底哪些派不上用场。
而有了重构，则只需要考虑：把一个简单的解决方案重构成这个灵活的解决方案有多大难度？如果答案是“相当容易”，那么你就只需实现目前的简单方案就可以了。
重构与性能
虽然重构必然会使软件运行更慢，但它也使软件的性能优化更易进行。除了对性能有严格要求的实时系统，其他任

 

何情况下“编写快速软件”的秘密就是：首先写出可调软件，然后调整它以求获得足够速度。
编写快速软件的方法：
1、时间预算法。
为每个组件分配资源（包括时间资源和执行轨迹）；每个组件绝对不能超过自己的预算，就算拥有“可在不同组件之间调度预配时间”的机制也不行。例如心律调节器，在这样的系统中，迟来的数据就是错误的数据。
2、持续关切法。
要求程序员在任何时间做任何事时，都要设法保持系统的高性能。
这种方式通常不会起太大作用。任何修改如果为了提高性能，通常会使程序难以维护，因而减缓开发速度。性能一旦被分散到程序各个角落，每次改善都只不过是从“对程序行为的一个狭隘视角”出发而已。
3、利用90%统计数据
90%的优化都是白费劲，因为难得被执行。
所以以一种“良好的分解方式”来建造自己的程序，不对性能投以任何关切，直至进入性能优化阶段。
优化的过程：测量-->优化-->编译-->测试-->再次测量.
使用性能热点测量工具“发现热点、去除热点”，直到获得客户满意的性能。
McConnell提供了关于这项技术的更多信息。

 很想了解相关技术,但是没有找到具体资料.倒是有两个开源项目

p-unit和junitperf
http://www.javapronews.com/javapronews-47-20030721ContinuousPerformanceTestingwithJUnitPerf.html