第16节 强力编辑器
1、我们认为你最好是精通一种编辑器，并将其用于所有编辑任务：代码、文档、备忘录、系统管理等等。
进行编辑活动时，你不必停下来思考怎样完成文本操作，编辑器将成为你双手的延伸，键会在滑过文本和思想时歌唱起来。
这就是我们的目标。
2、好的编辑器应该具有这些特性：可配置、可扩展、可编程、语法突显、自动缩进、类IDE特性。
3、编辑器对生产效率是有影响的。试想当我们需要一个字符一个字符或者一行一行移动时，按一次键，就以词，行，块的单位移动，显然效率更高。
4、然后做什么。选一种强大的编辑器，好好学习它。不断学习，减少你敲击的次数。设法扩展它，让它能胜任更多任务。
推荐两款编辑器：vim、Emacs
第17节 源码控制
1、原谅我们犯错的按钮是 UNDO 键，通常他们还支持多级 UNDO 和 REDO。而源码控制系统就相当于一个巨大的 UNDO 键，一个项目级的时间机器。源码控制系统（SCCS）能够追踪你在源码和文档中做的每一项改动。
2、应该总是使用源码控制，即使团队只有你一人，即使项目很小。
3、可以尝试的源码控制系统有 CSV、RCS、ClearCase 等。（那时 Git 还没流行起来）
第18节：调试
1、调试心理学。调试的目的是解决问题，不要因为别人提出 bug 而发起进攻。
2、当你目睹 bug 发生或者看到 bug 报告时，第一反应不要是“那不可能”。很明显已经发生了，把时间用在思考它为什么产生上面。
3、使数据可视化。例如循环引用问题，如果可视化的话可以很轻易地进行排查。
4、跟踪代码。发生 crash 我们能够查看系统的调用堆栈，但这些数据不一定够。对于非 crash 类错误，因为没有抛出，我们甚至不知道发生了什么。所以添加所谓的跟踪日志很有必要，这类日志最好采用统一规范，便于后期我们可以自动解析他们。
5、橡皮鸭，也叫小黄鸭调试法。遇到无法定位的问题时，对着小黄鸭（屏幕）解释自己的实现逻辑，很可能在说的过程中你自己就发现了问题所在。
6、不要第一时间怀疑 OS，IDE，三方库的问题，他们出问题的概率比你代码出问题概率小得多。我们应该首先确认和排查自己的问题。
7、对 bug 原因进行复盘。修复了一个 bug，不要就让它结束了，想一下，为什么它会出现了，如何避免。定位过程如果耗时较长，也需要复盘下为何花费了那么长时间，以及后续如何优化。
第19节 文本操纵
1、学习一种文本操纵语言。文本操作语言对于编程的意义，就像是刳刨机对于木工活的意义。
2、文本操作的案例。
我们的测试数据有好几万条，散落在不同文件，如果需要进行合并并转换为特定格式，手动处理是无法想象的。但如果使用 Perl 几个小时就可以完成。
数据库 schema 维护。可以写一组 Perl 脚本读取数据库 schema 定义的纯文本文件，根据它生成，用于创建数据库的 SQL 语句。schema 的 XML 版本等
生成 web 文档。可以编写 Perl 程序，分析数据库 schema，C 或 C++ 源文件，及其他资源，生成 HTML 文档。
文中很多案例使用 Perl，这些工作也可以使用 Python 代替或者 Shell 里的 awk，sed 代替。
第20节 代码生成器
1、作为程序员，有时会需要我们在不同地方重复相同信息。如果出现这种情况，你就可以考虑构建代码生成器了。代码生成器就是编写能编写代码的程序。
2、有两类代码生成器：被动代码生成器和主动代码生成器。
3、被动代码生成器是独立执行的。它可以用来生成模板，版权声明，每个新文件的标准注释等等。
4、主动代码生成器会在每次需要其结果时被使用。比如根据数据库 schema 创建代码。
5、代码生成器不一定要生成代码，它可以用来输出任何格式的内容，比如 HTML、XML、纯文本等。
比如 iOS 里的三方库 R.Swift[1] 就是一个根据资源名自动生成对应结构体的主动代码生成器。
第21节 按合约设计
1、注重实效的程序员会不信任自己，所以他们针对自己的错误行为进行防卫性编码。
2、按合约设计（Design By Contract，简写DBC）是 Bertrand Meyer 为 Eiffel 语言发展的概念。它的核心是用文档记载模块的权利与责任，并进行校验。它的目的是对函数做一些前置检查和后置保证，结合编译器的支持，我们能够尽早的发现代码问题。
3、DBC 有三个概念。
前条件：为了调用例程必须为真的条件。
后条件：例程保证会做的事情，其完成时的状态。
类不变项：其确保从调用者的视角来看，该条件总是为真。
4、Java 中的 iContract 框架是专为 DBC 设计的，它通过注释里的 @pre、@post、@invariant 声明这三个概念。它会读取注释并生成包含断言逻辑的源文件。Eiffel 则是通过 require、ensure、is 三个值表示对应概念。但是支持 DBC 的语言真的很少。
第22节：死程序不说谎
1、对待程序我们通常会有“它不会发生”的心理状态，这会导致我们忽视一些问题。对于注重实效的程序员来说，如果我们忽略了一个错误，将是非常糟糕的事情。
2、我们一些异常情况，我们应该及早崩溃，用于强调问题的存在。
3、引起崩溃的时候不要造成破坏，比如申请的资源还没有释放等情况。
4、死程序带来的额危害通常比有隐患的程序要小得多。