原书链接： http://www.amazon.com/Adaptive-Code-via-principles-Developer-ebook/dp/B00OCLLYTY/ref=dp_kinw_strp_1
这本书的标题很失败：它不是讲C#而是讲敏捷的。不知道是因为Agile这个词用的太多了还是怎么样，弄了个Adaptive在标题里，副标题里倒是有Agile，可惜太不显眼了。如果让我来翻译的话我觉得标题可以是：代码的敏捷之道（基于C#语言进行描述）。可能长了点，但毕竟能让人一眼就知道这本书到底想要讲什么。
全书分成三部分，第一部分对敏捷开发尤其是Scrum的各个要素、原则、实践做了介绍。第二部分对SOLID原则(Single Responsibility Principle, Open/Close Principle, Liskov SubstitutionPrinciple, Interface Segregation, Dependency Injection)分别做了解释。第三部分模拟了一个项目的两个Sprint让读者有一个直观的认识。总体上讲，这是一本可以让读者增长见识的书，但并不算如何深入。比如，如果你想了解单元测试，可以去看《The Art of Unit Test》，如果你想了解SOLID原则，可以去看Bob大叔的《Agile Principles, Patterns, and Practices in C#》，如果想了解DI，可以去看《Dependency Injection in .NET》。
下面是我在阅读过程中记下的一些书中的细节和体会。
前四章
- 在Sprint中，story的模式最好是这样的：As a XX, I want XX, so that。可以明确表明需求是由谁提出来的，具体内容是什么，目的又是什么。
- Sprint最好周二周三周四开始和结束，不要选择在周一周五这样的日子
- Sprint Evaluation常用的是用斐波那契数列打分的方式，如果时间紧的话也可以使用类似冒泡排序的方法。
- 所有开发团队的成员都应该参与Demo。
- Sprint应该有回顾，每次回顾都不是一次性的，下一次的回顾应该看一下上一次回顾中总结的问题有没有解决。
- 对于Build，当code coverage下降的时候也应该Fail
- 阶梯模式，将接口和实现放在不同的assembly中
- fusion log可以检查assembly bind失败，需要修改注册表才能打开fusion log,有专门的工具assembly binding log viewer
- chocolaty工具，可以下载和管理其他tool,例如filezilla
PostSharp等AOP库可靠attribute实现transaction, log等逻辑分离
- Command/Query Separation模式。command返回为空，总是让系统做点什么，可以改变系统状态。Query向系统请求返回数据，不会改变系统的状态。架构层面:Command/Query Responsibility Seperation. QQQuery可以直接访问DAL.
Null object pattern可以减少单元测试的数量
- Adapter模式分为class adaptrt和object adapter，后者更常见.
Impromptu可以实现类似dynamic的类型转换ActLike<T>方法，使用了反射，自动实现了object adapter模式
- re-motion或者re-mix可以动态生成实现多个接口.
单元测试的AAA模式也叫Given When Then模式。
单元测试部分一开始讲的太细，太初级，减分。
如果一个测试知道测试对象的实现细节而不是预期行为，那么这个测试就是over-specified
对单元测试这章表示失望
第五章
如果可以找到多个理由去改变一个类那通常意味着这个类有多个resopnsibility，这是不符合single responsibility原则的
adapter模式和strategy可以很好地实现single responsibility principle
第六章
open/close principle有两个定义，1988年Meyer的，是最常被引用的。
Software entities should be open for extention, but closed for modification.
Robot C. Martin有一个扩展的定义
第七章
不要使用decimal表示货币，考虑使用Money类型
使用Contract.Result<>在postcondition中获取返回值比使用本地变量更好
可以给接口定义一个ContractClass，这个类专门用于定义这个接口的Contract
contravariance颠倒了类的依赖关系，这与通常的直觉相反
covariance和contravariance是Liskov原则的基础
子类中不应该定义新的异常，而是应该继承父类的异常。否则客户代码可能会不得不引用新的异常，乃至每次有新的异常客户端代码都要修改。
第八章
接口隔离原则在权限控制中非常有用
第九章
sec parser好像就是illegitimate injection，是错误的，不应该有默认的无参构造函数，不应该在该构造函数中创建实现类。
可以创建默认的container，convention over configuration