22 死程序不说谎
早崩溃。不要破坏（trash），写入错误的数据
23 断言式编程
如果它不可能发生，用断言确保它不会发生。
断言时不要有副作用
24 何时使用异常
理解需求，异常是留给意外事件的
25 怎样配平资源
要有始有终：分配资源，使用它，释放它
嵌套的分配（一次性不只一个资源）
· 以与资源分配的次序相反解除资源的分配，如果一个资源含有对另一个资源的引用，就不会造成资源被遗弃
· 在代码不同的地方分配同一组资源，总是以相同的次序分配他们，这将降低死锁的可能性。
26 解耦与得墨忒耳法则
遵循得墨忒耳法则虽然可以减少模块之间的依赖，但是会带来很多委托方法出现，不仅增加无关的代码，还影响代码的执行速度，所以需要根据不同的场景折衷，违反规范来赢取性能的改进。
27 元程序设计
元数据
· 元数据（metadata）:描述应用的配置选项：调协参数、用户偏好
· 元数据严格意义上是数据的数据，宽泛意义上是对任何对应用进行描述的数据。（除了偏好外，还有资源等）
· 元数据是在运行时被访问和使用，而不是在编译时。
把抽象放在代码，把细节放在元程序
28 时间耦合
一开始编程都是按照时间的顺序去进行。但是一旦需要并发时，就出现了麻烦。
利用UML的活动图，分析工作流。
29 它只是视图
我们基于分而治之的理念将程序分成若干个模块，但是怎么管理组织不同模块（类）之间依赖确实一个难题。
我们从事件（event）这个概念出发，将新变化发送给感兴趣的对象。、
假如通过一个 例程（例程是某个系统对外提供的功能接口或服务的集合。比如操作系统的API、服务等就是例程）来自百度百科。那么例程就需要知道各个对象之间的交互有密切的了解。显然，我们可以采用订阅/发布的模式让某个订阅者只接受它感兴趣的事件。
CORBA Event Service 允许参与对象通过事件信道（公共总线）发送和接受通知。
MVC（模型-视图=控制器）模式有效地让模型与GUI分离，又与管理视图的控件分离。
模型：表示图标对象的抽象数据模型。模型对任何视图或控制器都没有直接的了解
视图：解释模型的方式。它定业模型中的变化和来自控制器的逻辑事件
控制器：控制视图。并向模型提供新数据的途径。它既向模型也向视图发布事件。
仍然有耦合，情看下一节 黑板
30 黑板
将警探办案将线索信息张贴在黑板的例子指出黑板方法的特性：
- 没有对象需要知道另外其他对象的存在，他们从黑板中查看信息，并添加他们的发现。
- 使用黑板的对象或者模块都有一个共同点就是围绕同一个目标或者功能，如在例子中是破案。
对于复杂多变的工作流，我们可以黑板来协调。
· 数据到达的次序无关紧要
· 在收到某项事实会触发适当的规则。
31 靠巧合编程
为什么不能靠巧合编程（看起能工作）：
· 它也许不是真的能工作依靠的边界条件知识偶然，在另一个条件下又不能工作了
· 没有记入文档的行为可能随着库的下次发布而变化
· 多余的调用让代码变慢
· 多余的调用可能引入bug
深思熟虑地编程
· 总是意识到自己在做什么
· 不要盲目编程，构建不完全理解的应用和使用你不熟悉的技术
· 按照计划行事，有条不紊！！！
· 依靠可靠的事物，如可靠的库。
· 为你的假定建立文档。
· 为你工作划分优先级，时间花在重要和最难的方面。
· 不做历史的奴隶，加入已有的代码不适用了，尽快替换。
32 算法速率
对于算法使用的资源。处理、内存进行估算。
O()表示法对我们度量的事物值设置了上限。
一些常见的O()表示法
O(1)
O(lg(n))
O(n)
O(nlg(n))
O(n^2)
O(n^3)
O(C^n)
虽然我们不用去设计编写排序等算法，但是 估算算法的阶 有利我们对自己编写的程序的运行情况有一定了解
33 重构
重构=重写+重做+重新架构
何时进行重构：
· 重复（DRY）
· 非正交设计
· 过时的知识
· 性能
早重构，常重构
怎样重构：
· 不要在重构同时增加功能
· 在开始重构之前确保拥有良好的测试，尽可能经常运行这些测试，这样能及早发现问题。
· 采取短小的步骤，并在每个步骤后进行测试，避免长时间的调试。
34 易于测试的代码
单元测试：针对合约进行测试。
为测试而设计：
在设计模块甚至是单个例程时既设计其合约也设计测试该合约的代码。
35 邪恶的向导
不要使用你不理解的向导代码
36 需求之坑
不要搜集需求，挖掘它们。
应该用明了的陈述句表达需求。有时候在陈述需求中会夹带着商业政策，而 商业政策是经常改变的。所以我们需要将商业政策与需求做区分。
在讨论用户界面时，需求、政策和实现之间区别可能会变的模糊不清。
重点
找出用户 为何做特定事情的原因，而不是他们目前做这件事情的方式。
建立需求文档：用use case（用例）来描述系统的特定用法。
相应的用例模板
抽象比细节活得更长久
维护项目的词汇表，利于沟通。
37 解开不可能解开的谜题
当遇到一个迷途难以解开的时候，解决的方法可能不在你现在思考的范围内。所以需要重新确定方法的约束，有些约束是绝对约束，而有些约束是先入为主。
不要在盒子外面思考-要找到盒子：我们需要确定问题的自由度，也就是约束
想想特洛伊木马
一定有更容易的方法
· 有更容易的方法？
· 你是在设法解决问题还是被外部的技术问题转移注意力
· 这件事情为什么是一个问题
· 是什么使它难以解决
· 它必须以这种方式完成吗？
· 它真的必须完成吗？
38 等你准备好
倾听反复出现的疑虑-等你准备好再开始
是良好的判断还是拖延
- 拖延：对于概念的验证出现“浪费时间”的厌烦
- 良好的判断，随着原型进展，肯呢个在某个时刻得到启示，突然意思到某个前提是错误的。
39 规范陷阱
对于有些事情，“做”胜于“描述”
40 圆圈与箭头
不做形式方法的奴隶
工具只是工具，要为我所用。