看名字就知道这本书写的是重构和设计模式的关系，是连接两者的桥梁。
书一共不到300页，两周左右肯定能看完（每天看半个小时）
设计模式很早就看过，当初看的时候很激动，觉得代码太漂亮了，想怎么改就怎么改。
也尝试按照书中的例子写了一些代码，感觉很好。
曾经把它当成了“银弹”，正好又开始写框架，所以到处都是。。。。
然而，在使用的过程中确没有经受住实践的考验：
1）有些开始认为会频繁改的东西偏偏后来没怎么改动---导致有一些废功能和废设计，也就是“过度设计”
2）经常改动的偏偏是一些没想到的东西，虽然开始的时候客户信誓旦旦的说不会改。。。
3）有一些设计的很好，经常改动，改动起来很简单----但是 比例小，并且我自己心里清楚：完全是模式用得太多蒙上的，设计的时候没想这么多
这让我很沮丧，这么好的东西怎么用不上呢？ 难道真要一个简单的hello也要用设计模式么？那如果后期不改怎么办？开始开发的时间浪费了可以忍受，但是看代码的人很痛苦啊。。。。
怎么办？自己这种水平连基本业务都理解的不深，怎么能知道哪容易变？即使业务了解的很深，也不能完全预知吧？
后来学习了重构，看了那本最经典的《重构-改善既有代码的设计》，开始没事就重构自己的代码--但通常局限于改名、抽方法或类。
也只是把这当成打扫代码的方式--清除一些表面的问题。
曾经也考虑过两个结合：
大体设计+持续重构
但设计到什么程度?是不是不设计，直接重构呢？答案当然是否定的。
其实最难的就是不知道设计到什么程度？
如何知道 重构的工作量/风险和设计的关系呢。
我个人认为的公式是
总工作量 = 设计阶段*设计程度+维护阶段*重构难度 （个人目前的想法）
而重构难度又和设计程度相关。
这就比较复杂了，而实际作业中的复杂度更高，不是一个公式就能解决的
希望这本书能够起到一个指导作用，或者给个思路也可以。
这本书和重构那本书都是讲重构的，区别或者说侧重点有什么不同呢？
以目前的理解来看：
重构一书讲的是使用工具等来去除代码的坏味道。而这本书侧重讲的是用设计模式+重构手段来改善代码，并且改善最初的设计--也就是书中所说的“趋向性设计”。
关于设计模式，本书中提出的一点很值得思考：
团队的水平参差不齐，有些人可能看用设计模式写出的代码比那种直接的代码更困难，怎么办？
书中的说法和我的比较一致----提高团队人员的水平。
很多事情都是这样的，短期看引入一种新的东西可能还不如旧有的方式来的更直接，更有效率，但从长期看肯定更好。
这就需要平衡学习成本和带来的收益之间的关系。
能循序渐进，旧有的新的东西共存，慢慢转化是最好的，但如果不行，就需要衡量和判断了。
把握这个度是困难的，但这也是作为管理者和架构师最重要的能力。
作为执行者来说，迅速接受和转化的能力是最重要的，我想这就是“学习能力”吧。
关于重构的意义，DDD里面的一张图很能说明问题（下面的是我自己画的。。。）
红点是一个突破，而要达到这个红点，需要前面不断的小的重构。也就是量变引起质变。
到达红点后，回头看领域模型，会让模型更完善，得到所谓的“深层模型”。
趋向性设计是一种新的思路，主要是避免“过度设计”
对于那些不知道设计到什么程度的认来说，这么书非常值得看，强烈推荐。
当然，这里记得都是一些思想了，具体的步骤书里非常详细，自己看问题不大(当然要对设计模式和重构都比较熟悉)
实际上，看完这本书，开始的问题“设计到什么程度就够了”，还是没有清晰的答案。。。
但已经感觉隐约间抓到了什么。。。好像和DDD里的东西有些关系，但是由于DDD理解的不深（应该是水平不够吧），没有抓住什么实质性的东西
希望以后的实践中可以自己给出答案。。。