工程传奇——制造平面

莫华枫

我的一个表兄是位工程师，早年在工厂里做过学徒，后来读了大学，还得了硕士学位，理论和实践功底都很扎实。有一次他问了我一个问题：钳工用的平板是怎么做 出来的。钳工平板实际上就是一块坚硬的铁板，表面非常平整，可以达到0.1mm以内的平整度。钳工用平板作为基准，进行装配、测量、加工等等工作。我想也 没想回答：用更平的平面作为基准，来加工平板。他反问我一句：那更平的平面是怎么加工出来的呢？这下我语塞。没错，更平的平面是怎么做出来的呢？
接着他告诉我，其实很简单。基本的加工流程是这样的：首先准备三块铁板毛坯，用平面刨床刨一下。这是粗加工，得到三块不是很平的平板。下面做的，是关键。 流程上不是很复杂，但用文字描述起来，需要费些口舌。为了方便，先给三块铁板编个号，分别是a、b和c。先在a板上涂一层“蓝油”（实际上就是一种蓝紫色 的油性染色剂，俗称蓝油），再把b板覆盖上去研合。于是，b板上的某些区域会染上一些蓝油。然后工人师傅用刮刀对染了色的区域刮削。刮完之后，把b板放在一边。把c板也放在a板上研合，也刮一遍。简单地讲，就是用a板作为基准，对b和c刮削。
下一步，用b板作为基准，对c和a刮削。再下一步，用c板作为基准，刮削a和b。如此循环往复，三块板轮流“坐庄”（作为基准），加工另两块。直到平整度达到要求。
整个加工过程的关键在于，开始的时候，几块板都不平整。当以a作为基准，研合b、c两块铁板的时候，a上突出的地方（或者都突出的地方）会在另两块表面染 出颜色。在刮削之后，这些染色区域会被削去一些。原则上，刮削之后，b和c两块板的凹凸应当相同。因为它们都是以a为基础加工而来，都应当与a互补。b突 出的部分，c也突出。于是，当用b为基准，对c刮削的时候，便削去了真正突出的部分（相对于真正的平面而言）。当然，实际上三块板都不平，以a为基准刮削 后所得的b和c并非完全凹凸一致。所以，需要通过轮流使用三块板做基准，反复刮削，逐步接近目标。
机械加工中，基准总是不可缺少。但是，当加工一个平板（或者平台）时，需要以平面作为基准。于是问题来了：平面是一个抽象的概念，并没有哪样看得见模得着 的东西叫“平面”。不过，利用一些基本原理，便可以虚拟地构建出这样一个抽象的基准。越是基础的东西，越是无法找到实物基准，此时必须利用基本的物理和数 学原理中的一些不变量，以获得虚拟的基准。比如，我大学导师的博士论文就是检测cd盘的表面平整度，精度要达到纳米级别，所使用的手段是光的干涉。再比如国际标准单位米、秒等，也都是以特定波长的光为基准制定的，利用的就是光速不变的原理。
与机加工的情况类似，软件开发的一些基础性任务，同样需要使用基本原理。

I have a dream。当然，我的梦没有King博士那么伟大。我的是真正的梦，就是晚上洗好脚，脱了衣服，钻进被窝，一面打呼噜，一面做的那种梦。我梦见我在编 程。一个个大大小小的form上布满了Button、ComboBox、Grid之类的控件，数据库飘荡在远处。而数据则在周围跳来跳去。我还记得头上长 犄角的上司布置的任务：把数据驱赶到界面和数据库里。当我挥动手中的鼠标，将一群数据赶向form时，它们高声叫道：“这不是我们的样子！”当我挥动手中 的鼠标，将另一群数据赶向数据库时，它们也在呻吟：“这不是我们的样子！”
“这不是我们的样子！”数据们就是这么说的。想想也是，界面上不是按钮，就是编辑框，跟数据真是一点不像。而数据库不是表，就是关联，非得把可怜的数据们大解八块，方可纳入。天哪，我该怎么办啊？
我承认，我没做过这种梦，都是我编的:)。
程序中的数据同界面、数据存储、数据库等的阻抗失配问题由来已久。各种尝试，如对象数据库，ORM等等，或多或少地存在些问题。如果我们回过头来，检视一些“古老”的技术，或许能够有所启示。
当Bell Labs的大师们创建Unix时，有着一个非常前卫的想法：一切都是文件。当然，在Unix中，他们只是部分地实现了这个目标。牛人们心有不甘，历经了千 辛万苦，终于在Plan 9中实现了这个梦想。这会儿我们先把跌宕曲折的故事搁在一边，单看这前卫的“一切都是文件”有什么用处。
既然“一切都是文件”，那么就是说不管什么都是文件。确切地讲，是任何东西都能当作文件看待。因而，“一切”东西，像什么系统参数、设备状态、图形界面、通讯端口等等，都可以当作文件处理。还有一点非常要紧。既然有了文件，那么自然少不了目录。自打Unix开始，文件目录就是一家人了，要是把目录也当成一种文件，也不算过分。
以界面为例，有一个form，上面有若干按钮和Grid。我们把form看作一个目录，按钮就是目录内的一个文件。如果要操作按钮，比如 enable/disable、修改按钮文本、控制3D效果等等，都可以通过向按钮这个“文件”写入数据即可。当然啦，如果删除这个“文件”，那么按钮也 就消失了。Grid是目录，里面的行和列也都是目录，而单元格是文件。要添加一行或一列，就是创建一个目录，如果要添加单元格，就在目录里加文件。
再来看看别的东西。以我为例。对，我。实际上是我的信息。首先，我的信息被存放在一块数据中。数据块进一步分成若干子块，分别存放不同的信息，比如姓名、 性别、生日、家庭住址、户籍所在地等等。这些子数据块可以再细分，比如姓名可以分成姓和名（如果在古代，可能还有子和号什么的。现在么，可能还有外号，英 文名，法文名什么的），生日分成年月日，住址分成国家、省、市、区等等。如果把这些信息按层次展开放在面前，会发现这和一个目录结构没什么区别。
如果我需要把我的信息填充到一个界面上，实际上也就是把一个包含文件的目录结构转换成另一种目录结构形式。同样的操作可以进一步推广到所有的资源上，只要我们可以把任何一种资源映射成文件和目录。
但是，有很多数据并非以树（即目录结构）的形式存在，它们更可能是图。对于这种情况，我们只需将所需的部分按树的形式剥离出来，即所谓的生成树，转换到目 标结构，便可以达到我们的目的。实际上文件系统可以通过link形成图，但使用上存在限制。如果真的试图构造这种统一的资源访问系统，那么就可以突破这些 限制。
既然所有的资源都归结到一种结构，也就是目录-文件结构，那么数据的生成、传递、转换等等，都在一个数据模型之下，也就不会存在阻抗失配问题了。
实际上，这里“文件”一词，已经异化，已经跟正经的文件毫不相干了。这里所谓的“文件”只是一种形式，并非真正保存在磁盘中的一坨数据。而是一种看上去、 用起来、特征和行为都像文件的东西。它物理上可能是一块内存，也可能是一个端口，也可能是数据库的某个字段。但无论它真正的出身如何，最终都被打扮成一个 文件，可以像文件那样操作、象文件那样访问，象文件那样管理。
进而，如果我们抛弃“文件”这个土气的称谓，转而使用更具现代感的名词，或许就更易于人们理解。比如节点、资源、流，或者其他存在或者不存在的名词。（相 信热爱中国传统文化的人或许会将其命名成“道”或者“元”什么的）。无论什么样的名称，其中的精髓就在于通过将资源按其内容不断细分，从而形成一个树形结 构。此外，不同资源（或者数据）之间存在的关系，进一步将资源（或者数据）组织成更复杂的图。从而构成一个统一，但高度抽象的体系。
对于这样的一个系统，如何访问呢？首先，需要定位一个资源。还是文件系统给了我们提示。文件系统里，通过路径定位一个文件。那么要定位一个资源，也可以用 路径。比如前面说到的那个界面上有一个名为myGrid的Grid，那么定位第5行第3列的单元格，无非就是：myGrid/row5/col3 /cell。为了增加检索的能力，可以给路径加上过滤条件，以及检索的方向等等。那么刚才那个路径也可以写成：myGrid/row[5]/col[3] /cell，或者干脆写成myGrid/cell[row=5 and col=3]。好吧，这看起来像什么？熟悉XML的同学可能早已高声叫道：“这是XPath！”。没错，这就是XPath，可以在树或者图中检索所需资源 的语言。在这种路径的支援下，我们可以在统一的资源模型中检索所需的数据，并构造出所需的结果。
为了消除阻抗失配问题，我们需要统一各种不同数据来源（资源）的表达形式（或者说数据模型）。这就需要我们从本质上检视各种数据资源的抽象特征。逻辑上， 数据、设备、界面，都由不同的部分构成，各个部分又由更小的部分构成。如此持续细分，最终可以构成一个树形结构。这种构造被形象地用“一切都是文件”概 括。而资源所存在的关系，则将这个模型变成更通用的图结构。无论什么样，它给予我们一个统一的资源访问模型，从而使得我们有机会最大限度地压缩了不必要的 管线代码，提高我们的生产效率。

为了制造平板，我们需要一个平面作为基准。为了获得这个不存在的基准，我们需要采用本质的原理来指导加工方法。同样，为了消除阻抗失配这种基础性的问题， 我们也不得不深入到问题的本质，通过对数据和资源根本性的抽象特征加以分析，以获得一个适用于所有资源访问的模型。所以说，基础的问题，还需要从本质上解 决。
当然啦，一位工人师傅刮削出一块合格的平板，需要长时间辛苦的劳动。而打造一个统一的资源访问系统，则是件持久而又艰辛的工作。