Adaptive Code Via C#读书笔记

原书链接：　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有一个扩展的定义

”Open for extension.” This means that the behavior of the module can be extended. As the requirements of the application change, we are able to extend the module with new behaviors that satisfy those changes. In other words, we are able to change what the module does.
“Closed for modification.” Extending the behavior of a module does not result in changes to the source or binary code of the module. The binary executable version of the module, whether in a linkable library, a DLL, or a Java .jar, remains untouched.
—Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices
(Prentice Hall, 2003)

第七章

不要使用decimal表示货币，考虑使用Money类型

http://moneytype.codeplex.com

使用Contract.Result<>在postcondition中获取返回值比使用本地变量更好

可以给接口定义一个ContractClass，这个类专门用于定义这个接口的Contract

contravariance颠倒了类的依赖关系，这与通常的直觉相反

covariance和contravariance是Liskov原则的基础

子类中不应该定义新的异常，而是应该继承父类的异常。否则客户代码可能会不得不引用新的异常，乃至每次有新的异常客户端代码都要修改。

第八章

接口隔离原则在权限控制中非常有用

第九章

sec parser好像就是illegitimate injection，是错误的，不应该有默认的无参构造函数，不应该在该构造函数中创建实现类。

可以创建默认的container，convention over configuration