程序员修炼之道 05：务实的方法②

本文主要是介绍程序员修炼之道 05：务实的方法②，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

不记录，等于没读。

这里是我阅读《程序员修炼之道》这本书的记录。

本章继续介绍一些提示和技巧。无论是编写代码还是做架构设计，又或者是写文档或估算进度，这些提示和技巧适用于软件开发的所有层级。只要在开发过程中牢记这些基本原则，你就能写出更好、更快、更健壮的代码，而且代码可读性更高。

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% 的漂亮用户界面，他们就会觉得软件差不多做好了。

所以，给人展示漂亮的用户界面原型可能有很大的风险，会让他们以为软件已经快做好了。如果你觉得你所在的环境或文化中，原型代码很有可能被误解，那么最好使用曳光弹的方法。

曳光弹式方法和原型有什么区别？