不记录，等于没读。
这里是我阅读《程序员修炼之道》这本书的记录。
本章继续介绍一些提示和技巧。无论是编写代码还是做架构设计，又或者是写文档或估算进度，这些提示和技巧适用于软件开发的所有层级。只要在开发过程中牢记这些基本原则，你就能写出更好、更快、更健壮的代码，而且代码可读性更高。
4 可逆性
在项目启动之初，开发团队决意采纳 X 数据库作为支撑平台。基于此决策，他们着手编码，期间所有涉及数据库交互的部分均借助于X数据库所提供的API进行构建。然而，就在项目进度已推进至 85% 之际，团队接到了一个令人愕然的消息：由于无法抗拒的外部因素，公司决定全面切换至 Y 数据库。此时，进行数据库迁移无疑意味着巨大的成本投入，原因在于 X 数据库已深深嵌入应用程序之中，其调用遍布各个角落。
造成这个局面的原因是开发小组制定了不可逆转的关键决定：使用 X 数据库。
没有什么是永恒不变的，如果你过分依赖某个事实，几乎可以肯定它将会发生变化。看上去好像是无解了，但其实不然。在系统的架构中，总存在一些相对稳定、变化可能性远低于其他组件的部分，如通信协议、抽象层等。倘若上述案例中的开发团队，在项目启动阶段未选择直接绑定某一特定数据库，而是将数据库概念抽象化，使其仅作为提供数据读写服务的角色存在，那么此刻应对数据库厂商的变更便能游刃有余。
要想让软件具备可逆性，需要遵循一条设计模式：依赖倒置。依赖倒置原则的定义是：
- 高层模块不应依赖于低层模块的具体实现，二者应依赖于抽象
- 抽象不应依赖于细节，细节应依赖于抽象
如果是第一次接触依赖倒置原则，看它的定义，你可能会云里雾里。没关系，让我们看一个例子。
计算机世界中，存储设备种类繁多，涵盖硬盘、闪存盘、网络存储、光盘等，相应地也有很多文件系统，比如 ext4、exFAT、NFS、ISO9660。根据存储设备的不同，文件系统在读取和写入数据的细节方面存在巨大的差别。这引出一个重要的问题，操作系统 (linux) 是如何跨设备复制的，比如从光盘复制文件到本地硬盘？
我们说过，不同的文件系统在读取和写入数据的细节方面存在巨大差别，linux 操作系统在复制文件时，Linux 需要了解文件系统的细节吗？会直接访问文件系统吗？就像下图所示的这样：
如果是这样，就违反了依赖倒置原则，因为高层次的 Linux 内核，直接依赖了低层次的文件系统，内核与文件系统耦合到了一起！文件系统的任何变化，都可能迫使内核更改，比如新增一个文件系统，则必须在内核层增加相应的代码。
Linux 的设计者显然不会这样设计，他们使用了依赖倒置原则：在 Linux 内核与文件系统之间抽象出一个 虚拟文件系统，虚拟文件系统是一套 API 接口，充当内核与与文件系统的中间人。如下图所示：
注意看图中的箭头。现在高层次的 Linux 内核不再直接依赖低层次的文件系统，而是依赖一个抽象层：虚拟文件系统。底层次的文件系统同样依赖这个虚拟文件系统，这就是依赖倒置。
每当有程序需要 I/O 操作时，它就向虚拟文件系统发送一个请求。虚拟文件系统定位合适的文件系统，通知设备驱动程序执行 I/O 与之进行通信。通过这种方式，用户和程序都不必知道硬件和文件系统的任何细节，这就实现了解耦。在每个文件操作的一端，虚拟文件系统以用户语言与用户沟通；在另一端，虚拟文件系统以具体设备文件系统的语言与各种设备文件系统沟通。最终，用户程序能够与任何文件系统交互，而且不必与文件系统直接沟通。
现在考虑另一个问题。当开发新的文件系统时，如何使它适合于 Linux 呢？答案在概念上讲非常简单。所有新设备的开发人员只需教新文件系统说“虚拟文件系统”语言(实现虚拟文件系统规定的 API 函数)，就能够使这个新文件系统加入到 Linux 世界中来，并且无缝地集成到其中。
下面是另一个完美之处：无论何时学习 Linux —— 30 年前还是30分钟前，Linux 文件系统都有相同的外观和相同的运转方式。此外，新的设备和更好的文件系统多年以来一直在不停的开发，它们都平滑简易地集成到 Linux 中来。这就是为什么在学生带着彩旗抗议战争的年代开发的操作系统，在学生拿着智能手机抗议战争的时代仍然能够很好地运转的原因。
那么未来又会如何呢？我们不知道未来会开发出什么稀奇古怪的新设备，毕竟对于技术，没有人可以保证什么。但是，我可以保证的是，无论出现什么新技术，它都可以与 Linux 协调工作。
5 曳光弹
曳光弹 是软件开发领域中的一种敏捷开发策略。这个术语源自现实世界中军事使用的曳(yè)光弹（tracer bullet），其特点是飞行时会发出可见光线，帮助射手观察弹道轨迹，调整射击角度，从而达到精确瞄准的目的。在软件开发中，曳光弹的概念被借用过来，寓意为通过构建快速、简化的功能片段，来“照亮”项目的前进方向，及时获得反馈并调整开发路线。
软件开发实际上是完成特定的需求，然而现实世界中：
- 需求可能是模糊的。构建从未做过的东西，甚至用户都从未见过的系统；
- 面临大量未知因素。使用了不熟悉的算法、技术或语言。
面对这些挑战，传统的方法是把各种需求逐条列出，制成文档，约束好每一项未知的东西等等。这种瀑布式开发在绝大多数场合被认为是过时的。务实的程序员会使用 曳光弹式 开发：
- 对开发进行优先排序，先从有疑问、有风险的重要需求开始编码。
- 找到整个应用中不确定的部分，搭建能跑起来的骨架，然后持续增加新功能。复杂项目会有各种组件、大量外部依赖、工具等等，通过搭建骨架将这些部分串接起来。
6 原型与便签
原型 用来尝试特定的想法。比如用木头制作鼠标模型，来验证手感。什么东西需要制作原型？答案是任何有风险的东西，任何之前没有尝试过或对最终系统来说很关键的东西，任何未经证实、实验性或可疑的东西，以及任何让你不舒服的东西。
制作原型旨在学习经验，其价值不在于过程中产生的代码，而在于得到的教训。一旦得到确定的结论，原型就会被扔掉。
这意味着原型不能用于产品！你可以用木头和胶带制作一辆看上去很棒的新车原型，但你不会在高峰时间驾驶它！
所以在制作原型时可以不用考虑正确性、完整性、健壮性等细节，可以用高阶的脚本或解释语言来实现。比如你要做用户界面原型，就可以聚焦在外观和交互上，而不用操心代码，你甚至可以用画图工具或 PS 来完成原型制作。
如果你做出了一个漂亮的用户界面原型，并将它展示给管理人员，这有可能带来麻烦。原因在于：
你可能知道，一座冰山 90% 的部分都在水下。软件开发也像一座冰山：开发一套漂亮光鲜的用户界面只占全部开发工作量的 10%，也就是说 90% 的开发工作是不可见的。这就导致，如果你给不懂编程的人展示一个完成度只有 10% 的用户界面，他们会以为整个软件的完成度只有 10%。而如果你给他们展示一个完成度为 100% 的漂亮用户界面，他们就会觉得软件差不多做好了。
所以，给人展示漂亮的用户界面原型可能有很大的风险，会让他们以为软件已经快做好了。如果你觉得你所在的环境或文化中，原型代码很有可能被误解，那么最好使用曳光弹的方法。
曳光弹式方法和原型有什么区别？
- 原型生成的是一次性代码，只是用于探索系统的特定方面，一旦获取经验和教训，就会扔掉原型，然后用目标语言重新编码。
- 曳光代码虽然简单但是完整，它是最终系统框架的组成部分。随着时间的推移，会将新的功能添加在这个框架中，把留白的程序补完。
7 领域语言
计算机的语言会影响你怎样思考问题，影响你怎样沟通问题。选择并使用某种编程语言不仅决定了代码的具体实现形式，还会影响开发者在解决特定问题时的思维方式以及他们与团队成员、客户之间关于技术方案的交流方式。
每一门语言都有一系列特性，使用面向对象编程思想设计的解决方案，与使用函数式编程思想设计的解决方案会有不同。更为重要的是，问题领域的语言也能启发程序设计的解决方案。
我们始终努力使用应用领域的词汇来编写代码。在某些情况下，务实的程序员可以更进一步，实际上使用领域所特有的词汇、语法和语义——即领域语言来进行编程。
领域语言专门针对某个特定领域，使用领域语言编写的代码即易于该领域人员理解(使用领域特有的词汇)，又可以提高效率。比如测试保龄球得分，你可以用 测试领域语言 这样写：
“投掷 4 次，每次得 3 分，调用计算保龄球得分函数，应返回 12 分”
测试领域语言会自动匹配文本中的短语和参数，然后构建成目标语言并完成测试。是不是又快又好理解。
与领域语言相对的是
通用编程语言。通用编程语言是为了解决广泛范围内的计算问题，比如 C 、Java 等。
8 估算
在某种程度上，所有的答案都是估算，区别仅在于一些比另外一些更精确。
估算结果的单位会对结果的解释产生影响。如果你说某件事需要 130 个工作日完成，那么听的人往往觉得实际要的时间会很接近这个数字。然而，如果你说的是“大约 6 个月”，他们就会认为还需要 5~7 个月不等。两个数字表示的时间周期是一致的，但是 130 天却暗示了比你想象得更高的精度级别。
| 采用的估算单位 | |
|---|---|
| 1-15 天 | 天 |
| 3-6 周 | 周 |
| 8-20 周 | 月 |
| 20+ 周 | 说出估算前再仔细想想 |
关于估算的建议：
- 问问已经做过的人，借鉴他人的经验
- 对估算结果基于的假设了然于心(假设没有交通事故，车里也有汽油，我会在 20 分钟内抵达)
- 如果估算建立在其他次级估算的基础上，务必考虑次级估算的准确性
- 根据代码不断迭代进度表(虽然管理人员可能反对)
- 被要求估算结果时，回答：“我等一下答复你”。放慢节奏，花点时间思考，总能得到更好的结果。
本文用到了以下书籍的观点：
- 《UNIX&LINUX大学教程》
- 《软件随想录》
每一份打赏，都是对创作者劳动的肯定与回报。！
