03程序员的修炼之道——从小工到专家读书笔记之一

第一节：我的源码让猫给吃了。

1. 开发过程中出现未曾预料的技术问题，交付晚了等情况，没关系，这些是无法避免的。发生了，我们就要尽可能想方设法地职业的去处理它们。程序员这个职业需要诚实和坦率，要敢于承认自己的错误。

2. 要对担负的东西负责，如果某些东西真的超出了你的控制范围可以不处理，需要尽早提出这个不可控的点。自己职责所在的事情就需要为其结果负责。当结果不达标，比如磁盘垮了，但你却没有备份代码，那这就是你的错。不要为出错的情况找借口，想老板说"我的源码让猫给吃了”，对问题没有任何帮助，而要向他们提供可行的解决方案，做什么能够最大的挽回局面。

第二节：软件的熵

1. 熵是一个热力学概念，指的是在某个系统中的“无序”的总量，热力学定律指出宇宙中的熵总是倾向于最大化。软件工程里中也存在这么一个定律，工程越庞大，代码的“无序”状态越严重。

2. 破窗理论指出，当一个东西本身就破旧时，不但没人爱惜，还会朝他仍石头，导致更多破窗。软件开发中也一样，如果我们项目留有很多“破窗户”（低劣的设计、错误的决策、糟糕的代码），之后接手的人也会倾向于是它变得更糟糕。如果代码很漂亮，你自己以及之后接手的人，都可能会格外注意，不把它弄脏的。所以我们应该尽早处理工程中遗留的问题。

第三节：石头汤和煮青蛙

1. 三个士兵返乡，路上饿了，路过一个村子，想跟村民借点吃的，但村民粮食贫乏不愿意出借。士兵们没有气馁，他们煮开了一锅水，往里面放了几块石头。村民好奇为他们在干嘛，士兵解释，这叫石头汤，如果能放点胡萝卜的话会更好喝。村民跑回家拿来了胡萝卜，士兵说如果放些土豆会更美味，又有人跑回家带来了土豆。后面又有人加了别的东西，最后士兵和大家一起吃了一顿饱饭。

2. 有时候你确切的知道自己需要什么以及怎么做，但请求许可这件事往往会遭遇拖延和漠然，每个人都会护卫他们自己的资源，这让事情变得复杂，这叫“启动杂役”（start-up fatigue）。这时候我们不应该等着所有事情都准备好，而应该先拿出“石头”煮起来，就是想让事情启动起来。只要是有益的事情，你把做出的一部分结果拿给别人看，然后告诉他们如果加的别的什么会更好，大家一般都会帮忙的。

第四节：足够好的软件

1. 使质量成为需求问题。很多时候对于质量的评估都是开发人员在进行，我们对质量要求低，交付时会出现很多问题，我们对质量要求高，会很大程度延误工期。所以指定需求时，把质量这一块考虑进去，在商定的时间内，由产品或者客户决定他们可以接受的质量是什么样的。

2. 没有完美的软件，应该知道何时止步。今天了不起的软件常常比明天的完美软件更可取。及早让客户使用，他们的反馈常常会把你引向更好的解决方案。

第五节：你的知识资产

1. 本杰明·富兰克林说过：知识上的投资总能得到最好的回报。这没问题，但遗憾的是知识是有时效的资产，特别是计算机领域。我们可以把我们了解的技术实现、工作经验视为知识资产，并使用管理金融资产的形式管理这些知识。

2. 经营知识资产可以从以下方面进行：
   定期投资：定期投入时间学习，即使很小的投资也是很重要的。
   多元化：作为底线我们需要对当前所从事的技术熟练掌握。但不要就此止步，技术的发展变化很快，掌握的知识越多，就越能更好的进行调整，赶上变化。
   管理风险：不要把所有的“技术鸡蛋”放到一个篮子里。
   低买高卖：新技术流行之前就掌握它往往比之后跟风再学得到更大的回报。
   这些知道方针里最重要也是最简单的就是：定期为你的知识资产投资。

3.具体方案介绍
每年至少学习一种新语言。
每季度阅读一本技术书籍，习惯之后可以一个月就阅读一本。
也要阅读非技术书籍，记住计算机是由人使用的。
在本地大学或者网上系统地学一门课程。
体验不同的环境，如果你只在 Windows 上工作，可以试下 Unix。如果你只使用某一种 IDE 那可以试试其他 IDE。

第六节：交流

1. 知道你想要说什么
   当我们面临会议，重要通话，或者只是撰写技术文档，问下自己你要表达的中心想法是什么，围绕这一点进行展开。
2. 了解你的听众
   比如你要做一场分享，你可以按照 WISDOM 的形式思考这几个问题：
   你想让他们学到什么
   他们对你讲的什么内容感兴趣
   他们有多富有经验
   他们需要多少细节
   你想要谁拥有这些信息
   你如何促使他们听你说话
   3.选择风格
   传达一个消息，可以是正式的邮件，黑板上的绘图，口头描述，及时消息，选一个适合你的目的的方式。
   4.让文档美观
   技术文档不光要注意内容也要注意形式，使用 LaTeX 或者 Markdown 进行排版。

5.让听众参与
引导他们提问，以问答的形式推进分享进程。

6、回复他人
你说什么和你怎么说同样重要。尽量不要忽视别人的询问，即使回复他们稍后再联系都会更好一些。

第七节：重复的危害

1. 可靠的开发软件，并让我们的开发更易于理解和维护的唯一途径，是遵循我们称之为 DRY 的原则：系统中的每一项都必须具有单一、无歧义、权威的表示。
   DRY 是 Dont’t Repeat Yourself 的缩写。

2. 重复的产生通常有以下种类：
   强加的重复。开发者觉得他们无可选择，其实是有一些方法让我们避免重复的。
   无意的重复。开发者没有意识到他们在重复信息。这个需要通过提高代码意识或者 CR 进行减少。
   无耐性的重复。开发者偷懒，因为重复可以让事情更容易。有时往往会遇速则不达，在这类重复面前我们应该更慎重。
   开发者之间的重复。同一个团队或者不同团队的几个人重复了同样的信息。需要一个统筹的人引导大家交流，提供一个中央区域，管理维护公共代码。

第八节：正交性

1. 正交性是一个从几何学中借鉴而来的术语，如果两条直线相交成直角，他们就是正交的。这在向量中的解释是沿着一条直线移动，你投影到另一条直线上的位置不变。
   在计算机中，该术语用于表示某种不相依赖性或解耦性。

2. 正交的好处是它提高生产效率，各个组件不相互依赖，使得改变得以局部化，促进复用，对于正交组件进行组合也可以提高生产效率，同时它还降低了代码的风险。

3. 延伸开来，项目团队的配合也应该遵循正交性。如果成员之间任务重叠较多容易让大家疑惑问题和责任的归属如何划分，这会造成配合的效率低下。
   代码设计的时候也应该尽可能考虑正交性，这需要结合一些特定的设计模式以达成目的。

第九节：可撤销性

如果某个想法是你唯一的想法，再没有什么比这更危险的事情了。在设计软件时，我们需要为可能出现的某种错误做准备，比如数据库的更换，开发平台的更换。这需要我们设计之初就考虑到构建一个相对灵活的架构。

第十节：曳（ye）光弹

1. 在黑暗中使用机枪射击有两种方式。
   方式一：你需要知道目标准确的位置，然后考虑当时的温度、湿度、气压、风力等一系列因素，计算完位置之后进行射击。
   方式二：使用曳光弹，发射时，曳光弹中的磷点燃，会照亮它经过的地方和最终位置，我们用曳光弹确认位置之后，就不需要那些繁杂的计算，直接使用机枪进行射击。

2. 在黑暗中发光的代码。通常一个项目的开发是非常复杂的，如果只是一个模块一个模块的开发，我们可能直到最后才能确认项目运行情况。更好的做法是，我们要让系统尽早的跑起来，然后根据需要给它完善细节。这样会有以下好处：
   用户能够及早看到能工作的东西。
   开发者构建了一个能在其中工作的结构。
   你有了可用于演示的东西。
   你能够感觉到工作进展。

第十一节：原型与便笺

1. 原型是你可以在忽略细节的情况下，考虑项目走流程，主要使用场景，他们是否正确，是否可行。通常也可以用用于演示

2. 原型制作是一种学习经验，其价值并不在于所产生的代码，而在于所学到的经验教训。那才是原型制作的要点所在。

3. 制作原型甚至不需要编码，你可以用便笺，白板上制作原型。制作原型时你需要尝试回答以下问题：
   主要组件的责任是否得到了良好定义？是否恰当？
   主要组件间的协作是否得到了良好的定义？
   耦合是否得以最小化？
   你能否克服确认重复的潜在来源？
   接口定义和各项约束是否可接受？

第十二节 领域语言

1. 计算机语言会影响你思考问题的方式，以及你看待交流的方式。

2. 领域语言通常是为了简化流程，用于配置或者控制应用程序。

3. DSL 可以理解为一个小型语言，它可以是扩展自已有语言。

4. 在设计一种 DSL 时，考虑可读性还是简单性时，主要权衡的应该是可扩展性和可维护性，因为通常大多数应用都会超出预期的使用期限。

第十三节 估算

1. 通过学习估算，并将此技能发展到事物的数量级有直觉的程度，你就能展现出一种魔法般的能力，确定他们的可行性。

2. 多准确才足够准确？130 个工作日和大概 6 个月，是不同的，显然，前者表示的精度更高。我们在做估算的时候也需要选好描述估算时间的单位值。

3. 估算结果怎么来呢。
   首先需要确认你是否理解了需求所涉及的各个方面，这个是前置条件。
   然后你需要建立系统模型，在这个系统中，把模型分拆成各个组件，然后给每个参数设置定一个值，最后根据模型计算一个时间。

4. 模型应该是一个动态的，它像一个人工智能模型，你需要持续不断的训练它，才能使它真正准确起来。每次的估算都需要记录，反思估算效果，找出影响因素，加入新的影响项或者调整对应参数。

5. 被要求进行估算时间时，我们可以这样回答：我等会儿回答你。然后花点时间仔细检查我们在这一节描述的步骤，你总能得到更好的结果。

第十四节 纯文本的威力
本节是第三章：基本工具，首节内容，章节介绍里有一句话：

许多新程序员都会犯下错误，采用单一的强力工具，比如特定的集成开发环境（IDE），而且再也不离开其舒适的界面。这实在是一个错误。我们要乐于超越IDE所施加的各种限制。要做到这一点，唯一的途径是保持基本工具集的“锋利”与就绪。

1. 纯本文由可打印字符组成，人可以直接阅读和理解其形式。
   这里强调可打印含义是字符时经过编码的可阅读字符，而不是二进制。这在现在看来几乎是不用争辩的，谁还会用二进制存储信息，但当时计算机算力和存储都有限，纯文本会占据更多空间，解码会耗费算力。但源于技术的发展，这些都是可以忽略不计了。

2. 纯文本的优点之一：保证不过时。这一点需要我们扩展纯文本能够自描述。自描述的含义是它自己能告诉我们它的含义。

3. 另外两个优点是杠杆作用和更易于测试。这里说的是我们可以利用各种工具 diff、fc、git，或一些语言例如 Python 等对纯文本进行各种调整和查看工作。

第十五节 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 可以做各种组合搭配，然后构建一个命令序列，让常做的事情自动化。

第十六节 强力编辑器

1. 我们认为你最好是精通一种编辑器，并将其用于所有编辑任务：代码、文档、备忘录、系统管理等等。
   进行编辑活动时，你不必停下来思考怎样完成文本操作，编辑器将成为你双手的延伸，键会在滑过文本和思想时歌唱起来。
   这就是我们的目标。

2. 好的编辑器应该具有这些特性：可配置、可扩展、可编程、语法突显、自动缩进、类IDE特性。

3. 编辑器对生产效率是有影响的。试想当我们需要一个字符一个字符或者一行一行移动时，按一次键，就以词，行，块的单位移动，显然效率更高。

4. 然后做什么。选一种强大的编辑器，好好学习它。不断学习，减少你敲击的次数。设法扩展它，让它能胜任更多任务。
   推荐两款编辑器：vim、Emacs

第十七节 源码控制

1. 原谅我们犯错的按钮是 UNDO 键，通常他们还支持多级 UNDO 和 REDO。而源码控制系统就相当于一个巨大的 UNDO 键，一个项目级的时间机器。源码控制系统（SCCS）能够追踪你在源码和文档中做的每一项改动。

2. 应该总是使用源码控制，即使团队只有你一人，即使项目很小。

3. 可以尝试的源码控制系统有 CSV、RCS、ClearCase 等。（那时 Git 还没流行起来）

第十八节：调试

1. 调试心理学。调试的目的是解决问题，不要因为别人提出 bug 而发起进攻。

2. 当你目睹 bug 发生或者看到 bug 报告时，第一反应不要是“那不可能”。很明显已经发生了，把时间用在思考它为什么产生上面。

3. 使数据可视化。例如循环引用问题，如果可视化的话可以很轻易地进行排查。

4. 跟踪代码。发生 crash 我们能够查看系统的调用堆栈，但这些数据不一定够。对于非 crash 类错误，因为没有抛出，我们甚至不知道发生了什么。所以添加所谓的跟踪日志很有必要，这类日志最好采用统一规范，便于后期我们可以自动解析他们。

5. 橡皮鸭，也叫小黄鸭调试法。遇到无法定位的问题时，对着小黄鸭（屏幕）解释自己的实现逻辑，很可能在说的过程中你自己就发现了问题所在。

6. 不要第一时间怀疑 OS，IDE，三方库的问题，他们出问题的概率比你代码出问题概率小得多。我们应该首先确认和排查自己的问题。

7. 对 bug 原因进行复盘。修复了一个 bug，不要就让它结束了，想一下，为什么它会出现了，如何避免。定位过程如果耗时较长，也需要复盘下为何花费了那么长时间，以及后续如何优化。

第十九节 文本操纵

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 就是一个根据资源名自动生成对应结构体的主动代码生成器。