《敏捷软件开发》读书笔记（四）

1、在进行用例（user case）分析时，我们关注用户素材（user story）和验收测试（acceptance test）。

2、提炼共性，寻找抽象。实体对象，塑造模型。

3、NullObject空对象模式：对于那种一些对象具有某种行为而另外一些不具有该行为的场景，空对象模式是一个很适合的解决方案。

4、核心模型（core model）或者说架构（architecture）是一个系统的基础结构，相对于它而言，其它的类和设计都是次要的。但是，这个基础架构也不是一成不变的，它会随着需求（或系统业务功能）的变化而逐步演化。

5、用例分析的时候，我们应该重点关注用例所揭示的行为，而不是数据。通过思考这些行为找出潜在的抽象。

6、抽象往往隐藏于用例或应用需求的背后。需求和用例都太关注于细节而至于不可能表达这种潜在抽象的一般性。因此，需要我们个人的思考突破这层思维障碍洞察其背后隐藏的共性。由此也说明：过度信赖工具和过程以及低估智力和经验都是灾难的源泉。

7、在一次迭代的开始，开发团队通常都会聚集在一个白板前，一起思考这次迭代中要实现的用户素材的设计。这种快速设计会话持续的时间通常会小于一个小时（怎么可能？随便来个异议，争辩几句半小时就没了，O(∩_∩)O）。如果产生了一些UML图，那么这些图会留在白板上，或者被擦掉。通常不会书面保留这些UML图（保留它干吗？它又不是真正的最终设计！）。会话的目的是发起一场思考活动，并为开发人员提供一个公共的、可以依据其展开工作的智力模型，而不是为了确定设计。

8、“向下转型”尽管是不被鼓励的，但是在某些场合下，它确实能给设计带来便利和简单。C++中使用dynamic_cast操作符非常适合于这种情况。

9、全局变量并非在本质上就是邪恶和有害的。

10、代码反馈对于任何设计来说都是极其重要的。UML图只是提供了缓存设计思路的作用，并不能揭示所有设计细节。