3. 基本工具
花时间学习使用这些工具，有一天你将会惊奇地发现，你的手指在键盘上移动，操纵文本，却不用进行有意识的思考。工具将变成你的双手的延伸。
3.5 调试
1. 你需要关闭每天用于保护自我的许多防卫措施，忘掉你可能面临的任何项目压力，并让自己放松下来。调试的第一准则：不要恐慌
2. 调试小心“近视”。要抵制只修正你看到的症状的急切愿望：更有可能的情况是，实际的故障离你正在观察的地方可能还有几步远，并且可能涉及许多其他的相关事物。要总是设法找到问题的根源，而不只是问题的特定表现
3. 当你遇到让人吃惊的bug，除了只是修正它外，还需要确定先前为什么没有找出这个故障。考虑你是否需要改进单元测试或其他测试，以让它们有能力找出这个故障
4. 如果bug是一些坏数据的结果，这些数据在造成爆发之前传播通过了若干层面，看一看这些例程中进行更好地参数检查是否能更早地隔离它
5. 如果你对bug进行处理的同时，代码中是否有任何其他地方容易受到同一个bug的影响？现在就是找出并修复它们的实际。
6. 如果修复bug需要很长时间，那需要思考，自己可否为其做点什么，让下一次修复这个bug变得更容易
7. 如果bug是某人的错误假定的结果，与整个团队一起讨论问题。如果一个人有误解，那么许多人可能也有
4. 注重实效的偏执
4.1 按合约设计
1. 前条件: 为了调用例程，必须为真的条件；例程的需求。在其前条件被违反时，例程决不应该被调用。传递好数据是调用者的责任
2. 对在开始之前接受的东西要严格，而允诺返回的东西要尽可能少。如果你的合约表明你将接受任何东西，并允诺返回整个世界，那你有大量代码要写了
3. 谁负责检查前条件？对参数进行任何显式的检查，就必须由调用者来完成
4.2 死程序不说谎
1. 尽早检测问题的好处之一是你可以更早崩溃
2. 当你的代码发现，某件被认为不可能发生的事情已经发生时，你的程序就不再有存活能力。从此时开始，它所做的任何事情都会变得可疑，所以要尽快终止它。死程序带来的危害通常比有疾患的程序要小得多
4.3 断言式编程
1. 如果它不可能发生，用断言确保它不会发生
2. 断言可能会在编译时被关闭——决不要把必须执行的代码放在assert
3. 不要用断言代替真正的错误处理。断言检查的是决不应该发生的事情
4.5 怎样配平资源
1. 资源有始有终，提示我们，分配资源的例程也应该释放它。比如文件操作，在同一个例程(函数)完成打开、关闭操作
2. 对于嵌套资源分配的建议：a. 以资源分配的顺序相反的顺序解除资源的分配。这样，如果一个资源含有对另一个资源的引用，你就不会造成资源被遗弃 b. 在代码不同地方分配同一组资源时，总是以相同的次序分配它们。这样降低死锁的可能性(如果进程A申请了resource1，并正要申请resoucre2，而进程B申请了resource2，并试图获得resource1，这两个进程就会永远等待下去)