原文引自：http://blog.joycode.com/microhelper/archive/2004/08/06/29865.aspx 作者：MicroHelper
第一， 度的把握。
项目开发的控制有四个要素：成本，时间，质量，范围。现在时间，质量已经决定，而且不由我们控制，那么为了控制成本，我们就只有对范围进行界定。
首先要制定出一个这段时间结束后要达到的目标。包括项目的性能，可扩展性，可以执行性，稳定性，友好性等等。一个清晰的目标能指引每个人向这个努力。而且这个目标对制定范围有着实际的指导意义。
另外一个是目前最迫切需要解决的问题，这是制定范围最优先考虑的。
还有一个是风险。（现在xxx驱动越来越流行，除了风险驱动之外，还有测试驱动，特征驱动，数据驱动，use case驱动等等）。怎么样制定一个范围，保证我们不会陷入泥潭，而又能段时间内拿出一个让别人耳目一新的 版本，使我们需要考虑的问题。
如何平稳过渡
小步快跑的方式是一个安全的办法，避免一次作太大的，无法预测的改动，分成几个小的阶段，步步为营。
接受变化
现在的系统虽然有问题，但是起码是比较稳定的，正常工作的，在work，right，best这条路上起码走到了right，要接受而且拥抱变化也是一个需要考虑的地方。
第二，技术的选择
对于架构，现在还没有一个统一的思想，选择是和上面范围的界定息息相关的，确定目标之后才能选择合适的架构。
焦点主要集中在
表示层和entity的绑定，entity的持久化，各层之间传递数据的方式，缓存对象之间的依赖关系，对象之间的协作，统一的安全控制的错误处理。配置信息的管理，unit test.
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
如果不是看了文章的标题，我想我会很容易的接受，并将其放入收藏夹。我不相信像作者这样有经验的人会犯文不对题的问题，所以我又仔仔细细将文章看了一遍，似乎也看出一点东西，但对于重构，作者确实是用笔太少。
让我们按照作者的思路来考虑这个问题，由于成本、时间等多面因素，我们不可能对一切变化做出准备，尽管有很多办法可以帮助我们刺激变化，及时发现潜在的变化，但难免的，在项目后期，我们还是会面临需求变更的危机，如果这个变化是我们所未预料的，并且牵一发动全身，那么，这种情况下，我们是否需要重构？
先让我们看看《重构》的作者是怎么定义重构的：“在不改变代码外在行为的前提下对代码做出修改，以改进代码的内部结构的过程。”请注意，重构是在不改变外在行为的优化。这就像人身上脏了要洗澡一样，是频繁、小度量的工作步骤。如果在前几次的迭代中还不能激发变化，我们就需要考虑度的把握，不要奢望在项目后期进行系统级的重构，它的代价太大了。如果你的改动将影响整个系统，那你只能想别的办法补救，所以，放弃重构吧，至少在当前这个可运行的版本中。
就像作者说的work,right,best一样，重构的前提是代码可以正常工作，目的是让代码更好的工作的。所以更多时候，我会把设计看作系统级的，把重构看作代码级，它们是两个阶段的两种工作，不能混为一团。
重构不是万能的，不要依赖于重构，也不要夸大了重构的功用，在很多时候，它并不能改善你设计上的缺陷。
