技术奇异点

Asimov《基地》系列的主线『心灵史学』（psychohistory）是不可能的科学。Asimov 年轻时受热力学启发构思了『心灵史学』。他自己后来坦承，热力学的简单分子运动和人的行为毕竟有天壤之别，如果稍稍年长一些可能就没有勇气仅凭这么牵强的启发构想如此宏大的科学。

步入老年之后，Asimov 开始创作《基地》三部曲的前传。第一部《 Prelude to Foundation 》描写 Seldon 还是一个从边远星系来到银河帝国首都的年轻数学家，虽然提出了『心灵史学』的概念但是自己都不相信它能成为预言的实用科学。守护人类的机器人 R.Daneel 用了几个月帮助他建立了把这门科学推向实用的决心，而那之后十多年的时间里尽管有 R.Daneel 作为帝国首相的全力协助，『心灵史学』的实用化进展甚微。

前传第二部《 Forward the Foundation 》中的一个转折点之后，『心灵史学』的实用化开始稳步前进。这个转折点是 Prime Ridant 的发明。通过 Prime Ridant ，所有参与『心灵史学』研究的数学家能够随时地持续地对其全部公式进行修改和审查。『心灵史学』的实用化程度逐步达到可以被称为『 Seldon 工程』的地步。

我当初读到这段的时候觉得 Asimov 描述的情节太过唐突。难道在 Seldon 困惑了十几年之后令『心灵史学』的研究一下子步入正轨的只是一个审查和存储工具？我记得，当时我把这段重新读了一遍，然后放下小说。过了几天，又读了一遍。这次我看到 Asimov 描写『心灵史学』的公式体系远远比现实中的数学复杂，突然豁然开朗 —— 当面对的复杂度超过某个程度时，高效稳定的持续集成和审查工具确实能起到让工作发生质变的作用。从复杂度来说，Asimov 笔下的『心灵史学』已经不太像数学，而是更类似今天的软件代码。所以一切明朗了：Prime Ridant 就是一个 version control 系统，拥有海量的存储，稳定的并发访问能力，方便的审查功能，以及优秀的用户界面（三维投射）。从小说的一些描写还能看出，Prime Ridant 还提供不错的 branching 功能，因为还未经过严格审查的修改只能进入相对不稳定的分支。

我不知道 Asimov 是否了解软件开发。即使他对软件开发的任何知识都闻所未闻，我也不会觉得把 Prime Ridant 和 version control 联系到一起有丝毫的牵强附会。在《 What Techology Wants 》一书中，《连线》的创始人已经说明了人类社会的技术和思想在并行独立发展中的自发汇聚现象：三个学者同时接近完成进化论（虽然达尔文第一个发表），20 个人同时独立接近发明电灯，非欧几何被至少三个数学家同时独立构建，三个物理学家同时接近完成相对论，等等。Asimov 作为一个对技术有独到见解的名家，在设想人类如何构建高度复杂系统的时候，描写的虚构工具和 version control 系统有众多相似之处，这种思想的汇聚本身就说明了 version control 在软件开发中的本质核心地位。

舍弃旧代码是程序员经常面对的一种诱惑。不必说维护旧系统的人经常要面对，就是开发新功能新产品的人也时常如此 —— 因为你经常被建议要借鉴一个老产品的 code base ，而你本能地想拒绝而重新打造一个干净的系统。幸运的是，很早以前我已经开始相信舍弃这些东西是不对的，不应该重写任何不必重写的东西。当几次看到那些险些被舍弃的旧东西节省了大量工作之后，我更是坚信对那种看起来又老又旧的东西，应该留出一个星期的时间来仔细研究它是否有用。这一个星期可能会节省一个月的工作。

这个原则后来读到的很多文章里得到印证。但是我记得开始编程的时候完全不是这么想的。最近一个星期我仔细回顾了一下这个转变过程。

2005 年开始看 Linux kernel 的代码。我当时有一种稍稍自卑的感觉，感慨 Linux kernel 的代码为什么能把一切情况都考虑周全。比如一个 40 行左右的函数，让我来写最多只能写出十几行，而差的那 30 行处理的是很重要又不容易考虑到的情况。

当时看代码是用《 Understand the Linux Kernel, 3rd Edition 》做主线。书上讲的是 2.6.x 版本（ x 是一个远小于 11 的数字）。而我参照的源代码是从网上下载的最新稳定版。从 2.6.1x 一直到 2.6.2x 更新了很多次。其间越来越多的看到书上的代码和最新代码的差异。跟随这些差异我开始阅读不同版本的 release notes ，以及针对特定修改的 mail list 讨论和 patch 注释。最后我意识到，书上的版本和最新版本之间的差异，往往就类似于上面提到的我能写出的十几行和实际的 40 多行的差异。为什么能把一切情况都考虑到？答案就是持之不懈地 Fix Bug 。

回想起来，尽管不够清晰，但这应该就是『绝不重写无必要重写的代码』这个想法产生的过程。没有人能把事情一次做对。旧的代码有很多错误，但是抛弃它们只是让已经犯过的错误有机会被重犯一次，加上新的错误。

另一方面，那些最后形成的代码，如果不比对《 Understanding the Linux Kernel, 3rd Edition 》上的旧版代码，似乎像是一次写就的。这是我最初的自卑的来源，也是很多初学者对编写代码的错觉。人们其实并不像最后结果体现的那样能一次就把事情做对，但是我们对错误的修正也没有必要直接体现错误本身。在循序渐进的过程中要把结果造就成一次就做对的面貌。如果你真的想回忆每个与之战斗过的错误，version control 才是怀念历史的地方。

已经有三年多没有碰过 Linux kernel 代码了。回顾起来，阅读它的代码让很多正确的想法第一次被植入到我头脑中。对于程序员来说，更多正确的有用的东西还是来自代码。

周末逛街。

量子计算可能是计算领域的下一件大事情。每次关于量子计算的新闻都能引起程序员们对于世界是否会被颠覆的讨论。幸好上帝似乎把这个门槛弄得很高，世界才能继续按照今天的规则运转。既然可能死在这上面，最好搞清除是怎么回事。可是我对量子力学的理解力也就限于《原子中的幽灵》那种科普水平了。加上五年里断断续续看到的文章，此文的一多半纯属猜测。

五年前我对量子计算模模糊糊的理解是利用量子的状态叠加特性，实现天然的并行计算，以至于能在多项式时间计算某些 NP 问题。但是，既然量子状态叠加会在被观察的一瞬间塌陷，所谓天然的并行计算带来的绝对好处也只能存在于结果产生之前。在从输入到结果的整个宏观态过程中，必然有一些缺陷来抵消天然并行计算的绝对好处 —— 这个缺陷是什么，这是五年来我对量子计算的疑惑。最近几个月根据新看的资料慢慢猜测，这个缺陷可能就是量子计算的结果并不能保证每次都正确，正确的概率是一个比较接近于一的数值。至于计算结果的不确定性是怎么和状态塌陷过程联系起来的就超出了我的理解能力。但是一般来说，用一种缺陷换取一种好处，已经是普通人能理解的宇宙准则了。基本上大多数人考虑一件事情如何影响自己的生活也只需要这种程度。

虽然量子计算的结果是不确定的，但庆幸的是验证一个给定的结果是否正确一般非常容易。比如，解一个二次方程，和验证一个数是不是一个二次方程的解，显然后者更容易。（但是也有极少数人相信两者一样容易。大多数人相信后者更容易，但迄今无人能证明。这就是著名的 P != NP 问题。）所以重复运行几次量子计算求解加经典计算的验证就能正确解决某些 NP 问题，虽然过程要重复几次并且需要额外的验证步骤，但是这些低阶的开销不会妨碍计算过程的时间复杂度仍然保持在多项式级别。

因此基本上，量子计算类似 GPGPU 计算这样的机制，能解决特定问题，但是不能解决通用计算的所有问题。就像编译器不可能用 GPU 加速，大概应用程序 UI 的代码也不会量子化。量子计算必须依靠经典计算的辅助（就像 GPGPU 需要依靠 CPU 的辅助）。等到量子加速芯片放到 MacBook Pro 里的那一天，世界不会被颠覆，只是系统中会多一套叫做 OpenQL （Q 是 quantum 的 Q）的开发框架。

开发桌面应用的时候，model-view-controller 是技术讨论中最为频繁引用的概念之一。所以一直想写篇关于 MVC 的。不过总是犹豫如何入手谈论这个复杂的话题。上周记录了一些学习 OpenGL 的想法，其中一篇和 MVC 有关，有人提出，MVC 是不是 over-engineering ？特别是 controller 这个概念是不是多余的？

质疑一：

没有人觉得这是 over engineering 么? 但凡任何一个把界面代码和业务逻辑代码进行一定程度的分离的程序不都有 view 和 model 么？至于二者之间怎么耦合方法可以多种多样，有必要非得显式设计成什么 controller ，而且还得按照 diagram 上的方式一本正经的互动？

我的意思是说，且不说设计模式是好是坏尚无定论，本来 GUI 编程里需要考虑的方方面面就多，如果 system GUI APIs 还非要强迫你去按照什么设计模式来把 M、V、C 的子类 plug in 才能用就未免太死板了（让我想到了当年失败的 EJB）。

质疑二：

我一直觉得 controller 是个多余的设计。

逻辑层提供 API 给显示层调用，提供（支持 multi-cast 的）callback 机制（callback function、event、或是 ugly 一点的 listener/observer）通知显示层。这样，对于显示层来说，主动被动（或称从上往下、从下往上）的情景都涵盖了，不就够了么，要单独搞个 controller 做甚？

就你说的例子，多个 view 同步可以用注册逻辑层的 multi-cast 的 callback 的确保一致性；异步本身可以封装在显示层内部（也就是逻辑层的 API 是同步的，显示层自己实现异步的假象），不关 model 什么事；drag-n-drop 更是显示层局部的代码互调，也不关 model 什么事。

首先，『如果 system GUI APIs 还非要强迫你去按照什么设计模式来把 M、V、C 的子类 plug in 才能用就未免太死板了』这个观点我认为是无的放矢了。我从来没有看到任何一个 framework 会强迫你按照 MVC 来实现一个程序。不管是 Qt 、Cocoa 、MFC 、Win32 SDK ，你总是可以用很简陋的方式去实现你的 UI 。或者如果头脑够健壮，你完全可以用意大利面条的方式实现复杂的 UI 。『EJB』倒的确是一个经典的强迫开发者实现一大堆 over-engineering 接口的例子，只是除了 Sun 当年会做这样的蠢事之外，这种灾难几乎没有被重复过（即便是同门的 AWT/Swing 也没有像 EJB 强迫接口实现那样强迫 MVC）。

至于说『异步本身可以封装在显示层内部』这种说法，我认为主要基于想象而不是实际的工程经验。实际中，异步操作不可能封装在显示层内部，更不要说很多异步操作还要求显示中间状态，这些中间状态的合法性要靠 model 来判断，否则就不是中间状态而是花屏了。

本文主要回答另一个问题：什么是 controller ，controller 是否必要。我初次接触 UI 开发使用的是 MFC 。MFC 的 UI 开发模式官方称为文档-视图（view-document）—— 没有提到 controller 。像 MFC 这类略过 controller 不谈的 framework 还有一些。

什么是 controller ，实体和规则

从下图表明的定义来看，controller 有三个特点：

1. 把 UI framework 的底层消息翻译成修改 model 的高层命令；
2. 设置 view 的状态（比如 active/inactive ，谁是 main view），注意 controller 修改的是 view 的一些简单状态，不能触及 view 的主要显示。其实这是 controller 最弱的一个可有可无的功能。
3. Controller 只能修改 model ，不能直接修改 view 。View 的修改必须由 model 的通知触发，由 view 本身完成。

上面的第一点可以用来划分在一个 UI 系统中什么是 controller ：一般来说，那些直接处理底层消息的回调函数就是 controller 。比如，MFC 里 CView 的 OnCommand() 。Cocoa 里 NSResponder 的 mouseMove() 。Controller 不需要非得是单独的一个或者几个类。那些认为 controller 是『多余』的质疑往往针对是否需要一个或者几个 controller 类，这是对 MVC 的误解。但是，虽然 controller 无需作为单独的类来实现，它的代码与 model 和 view 的划分还是有明确界限，而且 controller 代码的编写必须符合上面描述的第二点和第三点。

要特别说明的一点是，虽然 controller 不需要非得是单独的类，但是在复杂的应用中单独的 controller 类会带来好处。当 view 的不同实例需要对用户的相同操作做出不同的反应的时候（比如显示缩略图和显示稍大preview 的 view 可以是共用同样的 render 代码，但是会提供不同的操作），单独的 controller 类可以让代码更清晰。

所以，controller 只是告诉开发者如何把消息处理函数实现得更好，更容易维护的一个概念。把它理解成强迫你实现一个模块的 over-engineering 有点强迫妄想的。

Controller 不能做什么

一个通常的对 MVC 的误解是 controller 用来控制 model 和 view 。应该采用的规则是：

1. Controller 修改 model ；
2. Model 通知 view 发生了改动，但不能通知改动了什么；
3. View 自己负责更新可视化效果。

第一个问题是 controller 为什么不能修改 view 。答案是 controller 和 view 都不应该实现 submit change 的逻辑。Controller 的职责是把用户的操作（可以看作对 change 的低级描述）翻译成 model 可以接受的高级 change 描述，但是它不能干涉如何把 change submit 到已有的数据中。View 的责任是如实的表现 model 当前状态（确切的说是最近的合法状态），它也绝不应该涉足把一份增量数据合并到已有的数据集中这样的任务。这样的合并可以很简单，但是也经常很复杂，尤其是对于那些一致性约束很复杂的数据。一个应用应该只有一份代码负责这样复杂的逻辑，那就是 model 。

第二个问题是为什么应该由 model 而不是 controller 通知 view 发生了改变。答案是因为只有 model 知道何时应该通知。如果 model 提供的每个操作都是能原子化的保证数据一致的和同步的，那么 controller 调用这样的操作之后立即通知 view 也未尝不可。但是复杂的应用中，model 的操作往往是异步的、后台进行的、和并发的。如上面提到的，这种异步、后台和并发的特性不但是因为各种客观条件，而且有时是主动设计的。比如耗时很长的操作，又需要展示中间状态，就不能做成一个同步的操作。只有 model 能知道什么是最恰当的时间通知 view 进行更新。

暂态数据能不能由 view 管理

如果一份数据仅仅用于显示临时的可视化效果，能否让 view 直接管理？答案是具体情况具体分析。取决于如何定义暂态数据。比如，有些数据仅仅用于一个操作期间的显示效果，比如拖拽，或者长时间的 cache 更新。问题在于这样的长时间操作期间，UI 并不阻止用户发起其它操作，这些新发起的操作可能和原有操作交替或者同时运行，可能新操作的结果部分或者全部受到原有操作结果的影响，或者新操作可能会终止或者暂停原有操作。而这些复杂操作中可能就包括文档的打开或者关闭操作。

所以，暂态数据不是绝对不能由 view 管理，但是不要轻视 model 的作用。很多时候，让你的 controller 恪守第三条准则『Controller 只能修改 model ，不能直接修改 view 。View 的修改必须由 model 的通知触发，由 view 本身完成』，会让代码的整体复杂度大大降低，也能减少今后必须增加 UI 功能时所面临的引入新 bug 的风险。

什么是 controller

Model 和 view 之间的信息流动必须是有序的。如果假设没有 controller ，那么上面那个图里的五个箭头就必须都画在 model 和 view 之间。如果两个实体之间的箭头有五个之多，这些箭头的端点实际附着的地方肯定是不同的。这些附着点就在 model 和 view 就会形成不同的子模快。所以，除非能证明把这五个箭头中的两到三个是多余的，否则你还是不得不从 model 和 view 里重构出一个实体。只有让实体之间的箭头控制在一到两个，一个 pattern 才真正具有降低整体复杂度的意义。这也正是质疑一里所谓『二者之间怎么耦合方法可以多种多样』的问题所在，对于复杂的 UI 系统，『多种多样』并不是实际可以采取的方法，只是没有实际经验的臆想。

上面对 model 和 view 的讨论说明，这五个箭头缺一不可。所以，model 和 view 模块里实际包含着一些子模块来承担不同箭头的附着点。这些子模块的概念就是 controller 。

Controller 不是一个束缚代码物理位置的约定。它是一个设计的概念，帮助开发者理清信息流动的方向。它是一个刻度，让开发者明白 code base 的行为。你可以说，我的 code base 中 controller 很薄（或者很厚）而且我明白原因。但是如果你说：哦，那是 over-engineering ，我一直都把 controller 这个概念从头脑中清除出去，那你实际上不知道自己在做什么。