第三章 基本工具
第14节 纯文本的威力
本节是第三章：基本工具，首节内容，章节介绍里有一句话： 许多新程序员都会犯下错误，采用单一的强力工具，比如特定的集成开发环境（IDE），而且再也不离开其舒适的界面。这实在是一个错误。我们要乐于超越IDE所施加的各种限制。要做到这一点，唯一的途径是保持基本工具集的“锋利”与就绪。
纯文本由可打印字符组成，人可以直接阅读和理解其形式。这里强调可打印含义是字符时经过编码的可阅读字符，而不是二进制。这在现在看来几乎是不用争辩的，谁还会用二进制存储信息，但当时计算机算力和存储都有限，纯文本会占据更多空间，解码会耗费算力。但源于技术的发展，这些都是可以忽略不计了。
纯文本的优点之一是保证不过时。这一点需要我们扩展纯文本能够自描述。自描述的含义是它自己能告诉我们它的含义。例如，通过 <SSNO> 这样的标记，我们可以很轻松地将对应内容提取出来。
另外两个优点是杠杆作用和更易于测试。我们可以利用各种工具对纯文本进行各种调整和查看工作。
第15节 Shell 游戏
对于操纵文本的文件的程序员，命令 Shell 就是工作台。我们可以利用 Shell 启动各种应用、搜索文件、查询系统状态，甚至还可以构建复杂的宏命令，完成各种常见活动。
对于习惯 GUI 的开发者来说一直使用 Shell 有些极端。GUI 的好处是所见即所得，但他的缺点却是，所见即全部所得。GUI 环境通常受限于它们的设计者想要提供的能力。
比如我们想要做一件事：在一个代码仓库里，查找上周没有修改过的，使用了 awt 库的 java 文件。如果使用 Shell，可以执行：find . -name ‘*.java’ -mtime +7 -print | xargs grep 'java.awt' 如果使用 GUI，你可以设想一下，这个过程会很麻烦，也很容易出错。
Shell 可能比较晦涩，但是掌握之后它能很大程度提高你的效率。Shell 可以做各种组合搭配，然后构建一个命令序列，让常做的事情自动化。
第16节 强力编辑器
我们认为你最好是精通一种编辑器，并将其用于所有编辑任务：代码、文档、备忘录、系统管理等等。进行编辑活动时，你不必停下来思考怎样完成文本操作，编辑器将成为你双手的延伸，键会在滑过文本和思想时歌唱起来。这就是我们的目标。
好的编辑器应该具有这些特性：可配置、可扩展、可编程、语法突显、自动缩进、类IDE特性。
编辑器对生产效率是有影响的。试想当我们需要一个字符一个字符或者一行一行移动时，按一次键，就以词、行、块的单位移动，显然效率更高。
然后做什么。选一种强大的编辑器，好好学习它。不断学习，减少你敲击的次数。设法扩展它，让它能胜任更多任务。推荐两款编辑器：vim、Emacs
第17节 源码控制
原谅我们犯错的按钮是 UNDO 键，通常他们还支持多级 UNDO 和 REDO。而源码控制系统就相当于一个巨大的 UNDO 键，一个项目级的时间机器。源码控制系统（SCCS）能够追踪你在源码和文档中做的每一项改动。
应该总是使用源码控制，即使团队只有你一人，即使项目很小。
可以尝试的源码控制系统有 CSV、RCS、ClearCase 等。（那时 Git 还没流行起来）
第18节：调试
调试心理学。调试的目的是解决问题，不要因为别人提出 bug 而发起进攻。
当你目睹 bug 发生或者看到 bug 报告时，第一反应不要是“那不可能”。很明显已经发生了，把时间用在思考它为什么产生上面。
使数据可视化。例如循环引用问题，如果可视化的话可以很轻易地进行排查。
跟踪代码。发生 crash 我们能够查看系统的调用堆栈，但这些数据不一定够。对于非 crash 类错误，因为没有抛出，我们甚至不知道发生了什么。所以添加所谓的跟踪日志很有必要，这类日志最好采用统一规范，便于后期我们可以自动解析他们。
橡皮鸭，也叫小黄鸭调试法。遇到无法定位的问题时，对着小黄鸭（屏幕）解释自己的实现逻辑，很可能在说的过程中你自己就发现了问题所在。
不要第一时间怀疑 OS，IDE，三方库的问题，他们出问题的概率比你代码出问题概率小得多。我们应该首先确认和排查自己的问题。
对 bug 原因进行复盘。修复了一个 bug，不要就让它结束了，想一下，为什么它会出现了，如何避免。定位过程如果耗时较长，也需要复盘下为何花费了那么长时间，以及后续如何优化。
第19节 文本操纵
学习一种文本操纵语言。文本操作语言对于编程的意义，就像是刳刨机对于木工活的意义。
文本操作的案例：
- 我们的测试数据有好几万条，散落在不同文件，如果需要进行合并并转换为特定格式，手动处理是无法想象的。但如果使用 Perl 几个小时就可以完成。
- 数据库 schema 维护。可以写一组 Perl 脚本读取数据库 schema 定义的纯文本文件，根据它生成，用于创建数据库的 SQL 语句。schema 的 XML 版本等。
- 生成 web 文档。可以编写 Perl 程序，分析数据库 schema，C 或 C++ 源文件，及其他资源，生成 HTML 文档。
第20节 代码生成器
作为程序员，有时会需要我们在不同地方重复相同信息。如果出现这种情况，你就可以考虑构建代码生成器了。代码生成器就是编写能编写代码的程序。
有两类代码生成器：被动代码生成器和主动代码生成器。
被动代码生成器是独立执行的。它可以用来生成模板，版权声明，每个新文件的标准注释等等。
主动代码生成器会在每次需要其结果时被使用。比如根据数据库 schema 创建代码。
代码生成器不一定要生成代码，它可以用来输出任何格式的内容，比如 HTML、XML、纯文本等。
第四章 注重实效的偏执
第21节 按合约设计
注重实效的程序员会不信任自己，所以他们针对自己的错误行为进行防卫性编码。
按合约设计（Design By Contract，简写DBC）是 Bertrand Meyer 为 Eiffel 语言发展的概念。它的核心是用文档记载模块的权利与责任，并进行校验。它的目的是对函数做一些前置检查和后置保证，结合编译器的支持，我们能够尽早的发现代码问题。
DBC 有三个概念：
- 前条件：为了调用例程必须为真的条件。
- 后条件：例程保证会做的事情，其完成时的状态。
- 类不变项：其确保从调用者的视角来看，该条件总是为真。
Java 中的 iContract 框架是专为 DBC 设计的，它通过注释里的 @pre、@post、@invariant 声明这三个概念。它会读取注释并生成包含断言逻辑的源文件。Eiffel 则是通过 require、ensure、is 三个值表示对应概念。但是支持 DBC 的语言真的很少。
第22节：死程序不说谎
对待程序我们通常会有“它不会发生”的心理状态，这会导致我们忽视一些问题。对于注重实效的程序员来说，如果我们忽略了一个错误，将是非常糟糕的事情。
我们一些异常情况，我们应该及早崩溃，用于强调问题的存在。
引起崩溃的时候不要造成破坏，比如申请的资源还没有释放等情况。
死程序带来的危害通常比有隐患的程序要小得多。
第23节 断言式编程
如果它不可能发生，用断言确保它不会发生。例如，assert(string != NULL) 断言里写的为真的条件，当不为真时触发断言，程序退出。
断言检查的是决不应该发生的事情，而不是错误处理。
断言应该一直开着，不要在线上环境关掉它。断言对应的是一种强提示，它迫使我们必须遵守。像是单元测试，我们通常都使用断言的形式进行检查。
第24节 何时使用异常
异常很少应作为程序的正常流程的一部分使用，异常应该保留给意外情况。如果移除了所有的异常处理器，代码就无法运行，那说明异常正在被用于非异常情况中。
是否应该使用异常取决于实际情况。比如打开文件，文件不存在，是否应该发生异常？如果文件应该在那里，那么异常就有正当理由。如果不确定文件是否在那里，返回错误就可以了。
第25节 怎样配平资源
对于资源（内存、事务、线程、文件、定时器等）的管理要有始有终，你分配了对应的资源，就需要考虑对应的解除逻辑。要有始有终。
嵌套的资源分配，应该使用与分配次序相反的顺序进行解除。
异常的配平需要避免违反 DRY 原则。例如文件打开的异常情况，会导致 try..catch 有两条路径，那如何避免在正常流程和 catch 流程都处理 error 情况呢？C++ 可以依赖对象自动析构的特性，Java 可以依赖 finally 子句。
当无法配平资源时，需要设定一个规则，决定谁为某个聚集数据结构中的数据负责，以及如何负责。这里有点类似引用计数方案，无引用时释放。
自动化检查资源配平状态，可以依赖一些三方工具。