第3章：基本工具
工具放大你的才干。
本章讨论的工具包括：
- 使用纯文本存储数据
- 使用shell进行自动化
- 编辑器
- 源码控制
- 调试
- 操纵文本
- 代码生成器
14《纯文本的威力》
纯文本，又称“可读文本”，与之相对的是二进制格式。
“纯文本”相对而言的两个主要缺点：
- 存储空间更大
- 解析代价更高
“纯文本”的威力：
- 保证不过时
- 易于版本管理（方便查看历史的修改）
- 易于操控
15《shell游戏》
shell，在Windows上相当于”命令行“，与之相对的是”图形界面(GUI)“。
GUI使用简单：
- 好处是 WYSIWYG（What you see is what you get）
- 但坏处是 WYSIAYG（What you see is all you get）
命令行在某些情况下能更快完成任务。
对于自动化来说，命令行是必要的。
16《强力编辑》（编辑器）
建议最好精通一种编辑器。
建议你所选择的编辑器有如下特性：
- 可配置
- 可扩展
- 可编程
建议：
- 如果你用多个不同的编辑器，但只用基本特性：选一种强大的编辑器，好好学习它。
- 如果你有最喜欢的编辑器，但不使用全部特性：学习它，减少敲键盘次数。
- 如果你有最喜欢的编辑器，且尽可能地使用它：尝试扩展它。
17《源码控制》
其重要性无需多言。
18《调试》
没人能写出完美的代码，所以调试肯定会占用大量时间。
心理上：
- 接受事实：调试就是解决问题。
- 不要发出指责
- 不要惊慌
策略：
- 使数据可视化
- 跟踪
- 按顺序陈述那些自己在检查代码时想当然的事情，途中或许就能发现问题。
- 比起怀疑环境有BUG，先怀疑自己使用有问题
如果最终没有思路，只能使用”二分法“了。
当一个让你吃惊的BUG被发现时：
- 你需要意识到你的一个或多个假设是错误的。
- 证明你的假设
- 确定为什么先前没有找到
- 看是否有能更早发现它的机制
- 是否有另一些地方也有类似问题
- 警告团队其他成员可能有类似的假设
调试检查列表：
- 报告的BUG是直接原因，还是外在症状？
- bug在哪？编辑器里？系统里？还是你的代码里？
- 如何向同事解释这个BUG？
- 如果BUG通过了单元测试，那么单元测试是否有问题？
- 造成BUG的条件是否存于系统的其他地方？
19《文本操纵》
文本操纵很有用。
你应该学习一种文本操纵语言
作者的一些应用举例：
- 数据库schema维护
- Java属性（property）访问
- 测试数据生成
- 写书
- C与Object Pascal的接口
- 生成web文档
- 等等
20《代码生成器》
有时候你需要重复和过去类似的内容。为了省事儿，你可以：
编写能编写代码的代码
有两种：
- 被动代码生成器：生成一次就不用了，之后与生成器脱离关系。（比如VS的模板向导）
- 主动代码生成器：总在需要时生成，不用保存。（比如UE4生成generated.h）
被动代码生成器用途举例：
- 创建新的源文件
- 在编程语言之间进行一次性转换
- 生成计算昂贵的资源
主动代码生成器用途举例：
- 一种便利手段
- 多用于遵守DRY原则
代码生成器并不复杂，说白了就是一些print语句
代码生成器不一定必须生成代码。