一、迭进
Kent Beck关于简单设计的四条原则:
- 运行所有测试
- 不可重复
- 表达程序猿的意图
- 尽可能减少类和方法的数量
- 以上顾着按其重要程度排序
1.1 简单设计规则1：运行所有测试
设计的首要目的是设计出如预期一般工作的系统。
全面测试并持续通过所有测试的系统，就是可测试系统。看似浅显，但却重要。不可测试的系统不可验证。不可验证的系统不可部署。紧耦合的代码难以编写测试。同样，测试编写越多，就越会遵循DIP之类的规则。
1.2 简单设计规则2~4：重构
有了测试，就能保持代码和类的整洁，方法就是递增式地重构代码。完成修改，运行测试，保证没有破坏任何东西。所以，<b>测试消除了清除代码就会破坏代码的恐惧</b>。
重构的过程中，可以应用有关优秀软件设计的一切知识。提升内聚性，降低耦合度，切分关注切面，模块化系统关注面，缩小函数和类的尺寸，选用更好的名称。即消除重复，保证表现力，尽可能较少类和方法数量。
1.3不可重复
重复是拥有良好设计系统的大敌。Repeat Code代表extra work，意味着extra risk。大量重复可以用模板方法来消除。
1.4表现力
这需要尝试，让后来者易于阅读代码。
1.5尽可能减少类和方法
这是为了防止教条主义，片面追求设计原则，从而导致过度切分。例如给每一个类编写接口，所有行为都切分为数据类和行为类。但是这是优先级最低的一条。
二、并发编程
对象是过程的抽象，线程是调度的抽象。——James O Coplien
并发是一种解耦策略。它帮助我们把做什么（目的）和何时（时机）做分解开。这种解耦能有效改进应用程序的吞吐量和结构。
并发编程很难，往往不细心，你会搞出不知道什么鬼的恶心东西出来。看看下面的迷思和误解：
- 并发总能改变性能
并发有时候能改变性能，但一般在多个线程或处理器之间能风向大量等待时间的时候管用。 - 编写并发程序无须修改设计
这是完全bullshit。目的和时机的解耦代表着往往对系统结构产生巨大的影响。 - 在采用Web或EJB容器的时候，理解并发问题其实不重要。
实际上你最好理解并发在干什么。
总结一下：并发有额外的开销；正确的并发是复杂的；并发缺陷并不总能重现，所以被当做是“基因突变”；并发往往需要对设计策略的根本性的修改。
2.1并发防御原则
2.1.1单一权责原则
SRP：方法、类、组件应当只有一个修改理由。
- 并发相关代码有自己的开发、修改和调优生命周期
- 并发相关代码有自己要对付的挑战，和并发相关代码不同
- 并发编程错误不可控，可能会导致game over、
建议：分离相关代码和其他代码。
2.1.2推论：限制数据作用域
如我们所见，连个线程修改共享对象的统一字段时。采用临界区域形式保护（synchronize）。限制临界区数目，临界区数目越多：
- 忘记保护一个或多个临界区——破坏了共享数据的代码。
- 花力气保护一切都受到保护。（遵循DRY原则：Don't repeat yourself）
- 很难找到错误源。
2.1.3推论：使用数据副本和线程尽可能独立
避免共享数据的方法就是一开始就避免共享数据。
让每个线程在自己的世界里存在，不与其他线程论短长。
2.2执行模型
基础定义：互斥、线程饥饿、死锁、活锁。
执行模型：
- 生产者-消费者：生产者和消费者之间的队列是一种限定资源。
- 读者-作者模型：当存在一个主要围读者线程提供资源的共享资源，其偶尔才被作者进行写。协调吞吐量很重要。
- 宴席哲学家：获得所有资源，执行，否则等待。
2.3警惕同步方法的依赖和保持同步区域微小
同步方法之间的依赖会导致并发代码中的狡猾缺陷。Java有synchronize关键字，保护单个方法，然而，如果再同一共享类中有多个同步方法，系统就可能写得不太正确了。
<b>建议：避免使用一个共享对象的多个方法。</b>
三种对写代码保护方法：
- 基于客户端锁定
- 基于服务端锁定
- 适配服务器
尽量减少同步区。
2.4很难编写正确的关闭代码和测试线程代码
关闭的建议：尽早考虑关闭问题，尽早令其工作。
尽管测试无法证明代码的正确性，但测试可以降低风险。
测试的建议：编写有潜力暴露问题的测试，在不同的环境下频繁运行。
- 将伪失败看做是线程的问题：不要讲系统错误归咎于“基因突变”。
- 先使非先线程代码可工作：不要同时最终非线程缺陷和线程缺陷。
- 编写可插拔的线程代码：在不同配置环境下运行。
- 编写可调整的线程代码。
- 运行多余处理器数量的线程。
- 在不同平台运行。
- 调整代码并强迫错误发生。
