第13节 估算
1、通过学习估算，并将此技能发展到事物的数量级有直觉的程度，你就能展现出一种魔法般的能力，确定他们的可行性。
2、多准确才足够准确？130 个工作日和大概 6 个月，是不同的，显然，前者表示的精度更高。我们在做估算的时候也需要选好描述估算时间的单位值。
3、估算结果怎么来呢。
首先需要确认你是否理解了需求所涉及的各个方面，这个是前置条件。
然后你需要建立系统模型，在这个系统中，把模型分拆成各个组件，然后给每个参数设置定一个值，最后根据模型计算一个时间。
4、模型应该是一个动态的，它像一个人工智能模型，你需要持续不断的训练它，才能使它真正准确起来。每次的估算都需要记录，反思估算效果，找出影响因素，加入新的影响项或者调整对应参数。
5、被要求进行估算时间时，我们可以这样回答：我等会儿回答你。然后花点时间仔细检查我们在这一节描述的步骤，你总能得到更好的结果。
第14节 纯文本的威力
本节是第三章：基本工具，首节内容，章节介绍里有一句话：
许多新程序员都会犯下错误，采用单一的强力工具，比如特定的集成开发环境（IDE），而且再也不离开其舒适的界面。这实在是一个错误。我们要乐于超越IDE所施加的各种限制。要做到这一点，唯一的途径是保持基本工具集的“锋利”与就绪。
1、纯本文由可打印字符组成，人可以直接阅读和理解其形式。
这里强调可打印含义是字符时经过编码的可阅读字符，而不是二进制。这在现在看来几乎是不用争辩的，谁还会用二进制存储信息，但当时计算机算力和存储都有限，纯文本会占据更多空间，解码会耗费算力。但源于技术的发展，这些都是可以忽略不计了。
2、纯文本的优点之一：保证不过时。这一点需要我们扩展纯文本能够自描述。自描述的含义是它自己能告诉我们它的含义。
123-45-6789
<SSNO>123-45-6789</SSNO>
上面的例子中下面一条就是自描述的，我们能通过 SSNO 推断出这里存的就是社会保障号，另外根据 <SSNO> 这一标记我们可以很轻松的将对应内容提取出来。
3、另外两个优点是杠杆作用和更易于测试。这里说的是我们可以利用各种工具 diff、fc、git，或一些语言例如 Python 等对纯文本进行各种调整和查看工作。
第15节 Shell 游戏
1、对于操纵文本的文件的程序员，命令 Shell 就是工作台。我们可以利用 Shell 启动各种应用、搜索文件、查询系统状态，甚至还可以构建复杂的宏命令，完成各种常见活动。
2、对于习惯 GUI 的开发者来说一直使用 Shell 有些极端。GUI 的好处是所见即所得，但他的缺点却是，所见即全部所得。GUI 环境通常受限于它们的设计者想要提供的能力。
3、比如我们想要做一件事：在一个代码仓库里，查找上周没有修改过的，使用了 awt 库的 java 文件。
如果使用Shell，可以执行：
find . -name ‘*.java’ -mtime +7 -print | xargs grep 'java.awt'
如果使用 GUI，你可以设想一下，这个过程会很麻烦，也很容易出错。
4、Shell 可能比较晦涩，但是掌握之后它能很大程度提高你的效率。Shell 可以做各种组合搭配，然后构建一个命令序列，让常做的事情自动化。
第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，不要就让它结束了，想一下，为什么它会出现了，如何避免。定位过程如果耗时较长，也需要复盘下为何花费了那么长时间，以及后续如何优化。