【读书笔记】--代码整洁之道3
第九章 单元测试
敏捷和TDD运动鼓舞了许多程序员编写自动化单元测试，单元测试是确保代码中的每个犄角旮旯都如我们所愿的工作。
TDD三定律
- 除非这能让失败的单元测试通过，否则不允许去编写任何的生产代码。
- 只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
- 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。
PS:什么是生产代码，这里有点迷惑。
测试代码和生产代码一样重要，它可不是二等公民，它需要被思考、被设计和北照料。它该像生产代码一样保持整洁。单元测试让你的代码可扩展，可维护，可复用。原因很简单，有了测试，你就不担心对代码的修改，没有单元测试，每次修改可能带来缺陷，一个测试，一个断言。一个测试，对应一个概念。我们不想要超长的测试函数。
测试还应遵守以下5条规则。
1.快速 测试应该能快速运行，太慢了你就不会频繁的运行，就不会尽早的发现问题。
2.独立。测试应该相互独立，某个测试不应该为下个测试设定条件。当测试相互依赖，一个没通过导致一连串的测试失败，使问题诊断变的困难。
3.可重复。测试应该可以在任何环境中重复通过。
4.自足验证 测试应该有布尔值输出，无论通过或失败，不应该是查看日志文件去确认
5.及时。单元测试应该恰好在使其通过的生产代码之前编写。
第十章 类
1.类应该短小
2.单一权责原则(SRP)：类或模块应有且只有一条加以修改的理由。系统应该有许多短小的类而不是巨大的类组成。
PS：每个达到一定规模的系统都会包括大量逻辑和复杂性。管理这种复杂性的首要目标就是加以组织，以便开发者在哪儿能找到东西，反之，拥有巨大、多目的的类的系统，总是让我们在目前并不需要了解的一大堆东西中艰难的跋涉。
3.内聚：如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。内聚性高，意味着类中的方法和变量相互依赖，相互结合成一个逻辑整体。
4.为了修改而组织。开放闭合原则（OCP）：类应当对扩展开放，对修改封闭。我们可以借助接口和抽象类来隔离这些细节带来的影响。
第十一章：系统
将系统的构造和使用分开：构造和使用是不一样的过程。
PS：修建一栋大楼的时候，起重机和升降机在外面，工人们穿着安全服在忙碌。当大楼建设完成，建筑物变得整洁，覆盖着玻璃幕墙和漂亮的漆色。在其中工作的人，看完完全不同的景象。软件也是如此，将关注的方面分离。
1.工厂，有时候应用程序需要确定何时创建对象，我们可以使用抽象工厂模式。将构造的细节隔离于应用程序之外。
2.依赖注入（DI/IOC）。在依赖管理情景中，对象不应该负责实例化对自身的依赖，反之，它应该将这份权责移交给其他有权利的机制，从而实现控制的反转。
PS 现在的依赖注入组件比较多了，Autofac，Ninject等。
3.扩容：“一开始就做对的系统”纯属神话，反之，我们应该只实现今天的用户的需求。然后重构，明天再扩容系统，实现新用户的需求。这就是迭代和增量敏捷的精髓所在。 就像城市不断的再拆掉，再建设。
4.面向切面编程。AOP中，被称为方面（aspect）的模块构造指明了系统中哪些点的行为会以某种一致的方式被修改，从而支持某种特定的场景。这种说明是用某种简洁的声明(Attribute)或编程机制来实现的。
PS:MVC的Filter是个很好的AOP，可以从权限验证，方法进入前，方法进入后，返回结果前，返回结果后等这几个横切面进行编程。更好的组织代码。第十，十一章讲的设计只是一少部分。更多的可能要去参考专门讲设计模式之类的书。
第十二章 迭进
1.简单设计规则 1：运行所有测试。
紧耦合的代码难以编写测试。同样编写测试越多，就会越遵循DIP之类的原则，使用依赖注入，接口和抽象等工具尽可能减少耦合。如此一来设计就会有长足进步。遵循有关编写测试并持续运行测试的、明确的规则，系统就会更贴近OO低耦合度、高内聚的目标。
2.简单设计规则2 重构：
在重构过程中，可以应用有关优秀软件设计的一切知识，提升内聚性，降低耦合度。换句话说：消除重复，保证表达力，尽可能的减少类和方法的数量。
3.不可重复。重复是良好设计系统的大敌。它代表着额外的工作、额外的风险和额外不必要的复杂度。重复有多种表现。雷同的代码行是一种。另外的比如：
int size(); bool isEmpty();
这两个方法可以分别实现，但可以在isEmpty中使用size消除重复。
bool isEmpty(){
return size()==0;
}
不但是从代码行的角度，也要从功能上消除重复。
第十三章： 并发编程
并发是一种解耦策略，它帮助我们把做什么(目的)和何时（时机）做分解开。在单线程应用中，目的与时机紧密耦合，很多时候只要查看堆栈追踪即可断定应用程序的状态。而解耦目的与时机能明显地改进应用程序的吞吐量和结构。从结构的角度看，应用程序看起来更像是许多台协同工作的计算机,而不是一个大循环。单线程程序许多时间花在等待Web套接字I/O结束上面。
- 并发会在性能和编写额外代码上增加一些开销。
- 正确的并发是复杂的，即使对于简单的问题也是如此。
- 并发缺陷并非总能重现，所以常被看做偶发事件而忽略，而未被当做真的缺陷看待。
- 并发常常需要对设计策略的根本性修改。
一些基础定义：
在并发编程中用到的几种执行模型。
1）生产者-消费者模型
一个或多个生产者线程创建某些工作，并置于缓存或者队列中。一个或者多个消费者线程从队列中获取并完成这些工作。生产者和消费者之间的队列是一种限定资源。
2）读者-作者模型。
当存在一个主要为读者线程提供信息源，但只是偶尔被作者线程更新的共享资源，吞吐量就会是个问题。增加吞吐量，会导致线程饥饿和过时信息的积累。协调读者线程不去读取正在更新的信息，而作者线程倾向于长期锁定读者线程。
3）宴席哲学家。
许多企业级应用中会存在进程竞争资源的情形，如果没有用心设计，这种竞争会遭遇死锁，活锁，吞吐量和效率低等问题。
