即将到来的软件世界末日，作为程序员该如何应对？

软件的复杂度越来越高、人类程序员越来越无能为力、软件的 bug 越来越多、越来越致命：911 报警电话系统因 bug 宕机、人民生命财产面临严重威胁；汽车因 bug 自动自杀式地加速。

本文中微软的 Visual Studio 代码里 5,500 万行；空客上的软件 3,000 万行代码；特斯拉等高端车 1 亿行代码 ，不得不引发程序员们的深思，如何能做出牛逼的开发工具，能更好地控制代码复杂度、方便开发、尽量减少 bug。

2014 年 4 月 10 日，华盛顿州经历了六个小时没有 911 服务。当群众只要拨打求助电话时就会收到忙音。其中有一位西雅图的女性在一个陌生人试图闯进她的房间时至少拨打了 37 次 911 求助电话，然而当陌生人从最后一扇玻璃闯进她的起居室的时候，她从厨房里拿了一把刀吓唬了那个人，最终惊慌而逃。

那么为何 911 报警电话系统会宕机？根据当时的调查发现，事件根源被追踪到科罗拉多州恩格尔伍德城市中运行在服务器上的一款软件。该软件系统是由名为 Intrado 的供应商提供的，这个软件持续计数一个变量来记录路全国各地呼叫 911 的电话数量。Intrado 的程序员给这个变量设置了一个上限值。他们选了一个百万的数字。

在 4 月 10 号午夜前不久，计数器超过了设置的上限，由此产生了 Bug。因为这个计数器为每个打进电话的生成唯一的识别码，当计数器超过了限制，新的来电就被拒绝了。同时程序员没有预料到这个问题，他们也没有为此设置提醒。因此当时的人们并不知道究竟发生了什么。在华盛顿、加利福利亚、卡罗莱纳州、佛罗里达州和明尼苏达州的调度中心，这个为 1100 万美国人服务的 911，都因收到报警繁忙的信号而不知所措。直到第二天早上才发现 Englewood 城市运行的软件造成的这个问题，修复这个 bug 只修改了一个数字。

在不久以前，紧急救援电话是通过本地处理的。宕机这种情况发生的概率是很小的，而且很容易诊断和修复。移动电话的兴起以及新的功能出现——是否可以通过短信来拨打 911？或者发送音频给调度中心呢？开发一个依赖于互联网更为复杂的系统。第一次可能会遇到 911 宕机事件，但现在为止，这类情况已经发生了四次。

软件正逐渐地在蚕食这个世界。越来越多重要的系统被机械控制或者说被人们用代码来控制着。这样清晰的案例莫过于 2015 年的夏天，联合航空公司因为离境管理系统的问题而不得不在地面上延迟航班；在经历一次系统升级后，纽约交易所系统发生了交易挂起的问题；“华尔街日报”网站的首页崩溃；西雅图的 911 系统又一次宕机，这次是因为另外一个路由错误造成的。这么多软件系统同时故障让人感觉到一丝网络攻击的味道。更让人后怕的是，这些 bug 都发生在同一天晚上。

一位研究软件安全 35 年的马萨诸塞理工学院航空航天教授 Nancy Leveson 表示：“当我们使用机电系统时，我们通常会对其进行详尽的测试。”他因为 Therac-25 的报告而出名，Therac-25是一种放射治疗机，曾因软件错误导致 6 名患者死亡。“我们通常能够想到它能发生的所有事情，所有它能进入的状态。”例如，在铁路交叉路口控制火车运行的机电联锁有着如此多的配置选项；几页纸就能描绘出整个系统，你可以在每个配置情况运行真实的火车来观察它怎么运行。一旦你修建并测试了它，你就会准确的指导你正在处理的是什么了。

软件则不同。仅仅通过编辑某个地方的文本文件，相同的模块可以成为自动驾驶仪或者库存管理系统。这种灵活性不仅是软件的奇迹也是一种诅咒。软件是一直变化的，正因为它比其他的物理具有更多不可靠性，一个程序比其他消耗相同空间的内容复杂上千倍，而且还在无边界的增长着复杂度。Leveson 在一本书中写到：“问题在于，我们一直在尝试构建超出我们智力管理能力的系统。”

软件准确地做了我们让其做的事情，而出错的原因是它被告知去做错误的事情

关于工程故障的标准框架——反馈。例如，在医疗器械上的规定是在二战后开发出来的，在软件来临之前，就只有机电系统。这个思想就是通过局部可靠来完成整体的可靠性（例如，飞机引擎支持 40000 次的起飞和降落），同时计划停下来换掉这些坏掉的零件（两个引擎）。但是软件不会中断。软件做的只是我们告诉它做的。实际上它完成的很完美，而发生错误的原因是我们让它们做错的。软件故障是理解和想象的失败。Intrado 实际上有一个备用的路由，可以自动的切换，它可以立即恢复 911 服务，但是在 FCC 的报告中描述的是“这个场景是在应用程序的特定的点才会发生，这些地方没有设计任何自动纠正的措施。”

和一些物理事物相反，这是在代码之外创造事物的麻烦。正如 Leveson 提到的，“复杂性是我们人眼不可见的。”

现在这些改变我们做软件的方式的尝试看起来都是基于同样的前提：代码太难于理解了。在尝试理解这些办法之前，先理解他们为什么这样是很有意义的：编码是让它对思维来说如此不同，和以前的任何事物都不同。

技术性的处理通常会改变世界原本的样子，道路变得平坦。现在你几乎不能判断一个东西是否是翻新的，因为它被代码经常重塑。例如，当你踩下你脚下的汽车加速踏板，你不再直接的控制着一切；从踏板到油门没有机械连接。取而代之的是，你下发一个指令给软件来决定给引擎多少空气。这个汽车就是一台你可以坐进去的电脑。方向盘和踏板就类似于键盘上的按键。

和其他所有的事情一样，汽车已经被电脑化来支持新的特性。当一个程序用来负责油门和刹车时，当你离前车太近的时候，它可以自动慢下来，或者它还可以精确的控制燃料的注入来帮助你节约燃油。当它控制方向盘的时候，它能让你在偏方向的时候保持在自己的车道内，或者能引导你进入车位里。你不能不通过代码来做出这些功能。

软件已经能让我们制造出大多数的错综复杂的已知的机器。同时我们几乎没有注意到，因为所有的这些复杂的东西都被打包到了微小的硅芯片中，数以万计的代码都在里边运行。但是正因为这些复杂性对于我们来说是不可见也不意味着不存在这些复杂性。

大名鼎鼎的荷兰程序员 Edsger Dijkstra 在 1988 年写过一段话：“必须要在概念层次上进行思考，比以前只面对单一的思考更深刻一些。”Dijkstra 把这个当作是一个警告。随着程序员热切的将软件运用到重要的系统中，他们会成为构建世界的主角，但是 Dijkstra 认为程序员们可能高估了自己。

软件工程师不理解，也并不关心他们正解决的问题

什么致使编程变得困难？编程需要程序员像电脑一样思考。在计算的早期，代码采用 1 和 0 来表示就更显得奇怪了。任何人看着程序员的肩膀就像是并排的“100001010011”和“000010011110”一样，你就知道程序员与他们需要解决的问题有多远了；不能判断他们是否在尝试计算火炮的轨迹或者模拟一场 tic-tac-toe 的游戏。类似 Fortran 和 C 这些变成语言的简介像英语和工具，以“集成开发环境”出名，或者叫做 IDE，他们帮助纠正简单的错误（例如微软 Word 的语法检查，仅对代码有用）却是模糊不清的，程序员不直接处理问题的事实，而是花时间写机器指令。

MIT 的软件安全专家 Leveson 说：“现在的问题是开发和解决软件问题的软件工程师不了解问题所在，同时他们也不去关心问题。”原因就是他们把自己太过于封闭在自己的编码工作里了。 他评价道这些 IDE：“软件工程师喜欢提供各种各样的工具和东西来解决错误，软件发生的严重问题与需求有关，而不是简单的编码错误。”例如，当你写代码来控制汽车的油门时，重要的就是什么时候和怎样来打开油门的规则。但是这些系统变得如此的复杂以至于几乎没有人可以让他们在脑子里有直观的理解。Leveson 说：“在车里已经有上 1000 万行的代码了。你根本无法预料会发生什么。”

2007 年 9 月份，Jean Bookout 和她最好的朋友在高速路上开着一辆丰田的凯美瑞，突然她的汽车加速踏板卡住了。当她把脚拿开踏板时，汽车并没有降低行驶速度。同时她又尝试刹车，但是刹车看起来也失去了电源供给。 汽车冲进路边之前留下了 150 英尺的防滑标记。与她同行的乘客死亡。Bookout 一个月后，才在医院醒来。

这个事件只是近十年来丰田汽车对所谓的“意外加速”调查中的一个。丰田把事故归咎于糟糕的地垫设计、迟钝的踏板、和驾驶员的错误，但是外部调查得到的错误原因是车辆软件问题。国家高速安全管理中心从 NASA 的团队中请了软件专家来审查丰田的代码。过了大概 10 个月，NASA 的团队也没有发现软件导致故障的证据，但他们也说也不能排除可能性。

直到 Bookout 的诉讼阶段，有人终于发现了令人信服的证据。Michael Barr 原告的出庭证人，花费了18 个月来分析丰田的代码，从 NASA 遗漏的地方发现了错误。Barr 描述的是“意大利面似的代码”，这是程序员用于描述软件变得混乱的行话。当代码积累了很多年以后就变成了意大利面了，特性一个接一个的加上去，功能已经很混乱了；终于代码变得无法跟踪了，更不用说具体的测试功能缺陷。

Barr 的团队使用了事故中的凯美瑞汽车的相同模型，演示了有超过 1000 万种可能性来造成运行中的电脑发生不可控的加速故障。他们演示了只要一个小小的比特的数据发生变化，电脑内存中的一个比特变成 0 或者 1，都可以让汽车变得失去控制。丰田实施的故障安全代码还不能保证让汽车停下来。Barr 测试说：“你用软件来监控软件，如果软件故障了，同时这个程序或者这个崩溃的应用会保存至一天，但是因为他不工作了，所以也无法保存一天。”

Barr 给原告做出的证词，让丰田因 Brookout 和她朋友家庭的伤害赔偿了 300 万美元。根据纽约时报的报道，这是第一次丰田类似的案件中指控电子油门控制系统问题的判罚，同时这也是第一次丰田被发现需要对此因为意外加速的事故负责。双方决定在赔偿性判罚直接完结此案。最后，丰田召回了超过 900 万辆汽车，支付了大约 3 亿美元来解决相关的意外加速问题。

中国发布会上丰田章男鞠躬致歉

对软件来说还有更多糟糕的日子。对我们来所把软件做好越来越重要，因为如果我们没有这样，随着软件变得越来越复杂和相互关联，随着它控制着更多关键的功能，这样生活就会变得更糟糕。

问题是程序员们很难保持他们的创造力。自从 1980 年，程序员的工作方式和他们使用的工具的变化都不大。有一个小而一直增长的共鸣就是这个状态是不可持续的。Chris Granger，一位在微软工作的开发 Visual Studio 的高级程序员说：“即使是非常好的程序员都会努力去理解他们正在使用的系统。”在他在微软工作的时候，他安排了端到端对 Visual Studio 的研究，到目前为止做的唯一一次，大约用了一个半月的时间，他在一个单向镜后边看了人们写代码。他说：“他们怎么使用工具？怎么思考？他们怎么坐在电脑面前，他们是否会用鼠标，什么时候不用鼠标？所有的这些事情都有固定的模式，但是我们都还没有实际测试过。”

这个发现令他感到惊讶。他说：“Visual Studio 是世界上最大的独立软件，它有超过 5500 万行代码。还有一件我在这个研究中发现的事情就是超过 98% 的代码都是不相关的。我获得的最大的一个发现，就是基本上人们都在大脑里玩电脑。”程序员很像围棋选手试着戴着眼罩玩一样，他们大部分的精力都被消耗在大脑里描绘出每个模块的样子，所以对于他们来说就没有多少剩余来思考游戏本身了。

计算机的运算能力在过去的 40 年里，每隔 18 个月都会翻倍。但是为什么编程没有改变呢？

John Resig 是一个有名的 JavaScript 程序员，他的软件支持了大概半个互联网，同时也是在线教育网站 Khan Academy 的技术主管。在 2012 年初，他在网站的计算机科学课程上很纠结。为什么学习编程这么难呢？根本的问题好像是代码是很抽象的东西。写软件和用钢筋混凝土来修桥不一样，修桥你可以看到钢筋混凝土。为了开发一个程序，你输入单词。当你想改变程序的表现时，假设它是一个游戏，或者网站或者一个模拟运动，你实际改变的是文本。所以那些做的好的学生，这些留下来的学生，都是那些能在文本中一步一步，以计算机的方式来思考问题，跟踪每一步中间计算的人。Resig 和 Granger 一样，都在思考是不是不得不用这种方法。计算机的运算能力在过去的 40 年，每隔 18 个月都会翻倍。那为什么编码却没有变化呢？

事实上，他们两个都在相同的时间考虑同样的问题，这不是一个巧合。他们俩都是看了一个相同的具有标志性意义的演讲，这个演讲是在 Montreal 酒店里一个叫做 Bret Victor 的电脑研究人员给一组软件工程师学生做的。这个演讲在 2012 年 2 月上传到网站上以后就像病毒一样开始传播，引起了两个大胆的争议。第一个是我们开发软件的方式从根本上被打破了。第二个就是 Victor 知道怎么解决它。

Bret Victor 不喜欢写代码。他说：“这听起来很奇怪，当我想创造一个东西的时候，特别是我想通过软件的方式来创造东西时，我会首先推开一层让人厌恶的东西，这些不是我想要的，这就是我要在文本编辑器里写很多的文字。”

“有一个非常坚定的信念，这是错误的做事方式。”

Victor 有着 David Foster Wallace 的风采，闪电般的智慧使人难以置信。他运营着一个研究未来计算的实验室，他看起来对技术的兴趣比使用它的人少。像其他好的工具制作者，他看待世界的方式是部分技术与人文是相等的。他毕业于加州理工大学电气工程专业，然后在加利福尼亚大学伯克利学院毕业后，在一家开发音乐合成器的公司工作。 这个问题完美的符合他的双重人格：他能花费足够多的时间来思考演奏家通过键盘来弹出音乐，这是他们双手的一个延伸方式，同时也能花费足够多的时间来思考数字信号处理的数学问题。

直到他做了这个演讲让他变得有名，就是 Resig 和 Granger 在 2012 年初看的那个视频，Victor 终于明白了差不多贯穿他工作的原则。(他称这个演讲为“原则上的发明”)这个原则是：“创造者需要一个和他们创造的东西有时刻的联系。”编程的问题就是它违反了这个原则。这是软件系统如此难以让人理解的原因，bug 的流行：程序员一开始就对他要做得就很抽象。

他说：“我们目前对于计算机程序是什么的概念是从上世纪 50 年代的 Fortran 和 ALGOL 得到的。这些语言是给打卡设计的。”那个代码对于现在来说就是屏幕上像 C 语言，Java 语言这样的字母（从 Fortran 和 ALGOL 衍生而来），代替了这些一大堆的有洞的卡片，也没有一丝生机和直接。

对于 Victor来说，人们试图通过文本编辑器来理解癌症的想法是让人吃惊的

文字处理有一个类比。以前你在程序里看到的文档就是文本本身，为了修改层次或者字体或者边界，你不得不写特色的“控制代码”，或者能够告诉计算机做什么的命令。举例说明，“这一部分的代码应该是斜体。”问题是你不能看到这些代码的效果，直到你打印了文档。预测你将获得的东西是很困难的。你不得不想象代码被计算机处理处理后是什么样子，所以你不得不让你脑子里时刻都想着电脑。

然后“所见即所得”出现了。当你把文章中的一段文字标记为斜体时，这字母就马上就在屏幕上变倾斜了。如果你想改变边界，你可以拖动屏幕上方的标尺，然后马上就可以看到变化了。这里的文档看起来就像是真实的东西，一个你可以随意处理的东西。只需要通过观察就可以判断是否有问题。这个复杂系统的控制是由文档层和格式引擎实现的，这个引擎让人们可以通过点击页面来访问。

Victor 的观点是编程本身就应该如此。对他来说那些重要的工作，例如设计可适应粘性控制系统或者尝试理解癌症，通过盯着一个文本编辑器这种想法是相当可怕的。这正是程序员们要在未来某一天去解决的。

有足够多的先例来印证这不是疯狂的想法。例如，Photoshop 提供了强大的图像处理算法给那些可能不知道算法到底怎样的人使用。这是软件最复杂的一块，复杂只是对合成器来说复杂，但是软件中的按钮，拖动条对用户来说就像演奏乐器一样。Squarwspace 一家可能最有名的播客广告商，开发了一款软件让用户可以通过点一点就可以构建一个网站，代替以前的编写 HTML 和 CSS 代码。这个软件足够强大，足以完成以前由专业网站设计师。

但这些只是少数的例子。压倒性的事实是当某人想用电脑来做一些有趣的事情时，他们不得不写代码。Victor 是一个理想主义者不认为这是一个机会，而是程序员道德的失败。他的演讲是对行动的呼吁。

演讲的核心是一系列试图演示当前可用的工具来处理电路设计，计算机模拟，算法调试来说是多么的原始，和好的工具应该是什么样。他的例子都很有名。那些吸引人们想象的是，讽刺的是，他们的界面都是不重要的。它演示了一个分屏的游戏，表面上看起来像马里奥，代码则控制着另外一侧。当 Victor 修改代码游戏中的画面就会相应变化：他减小一个数字，引力大小，马里奥就飘起来了；他增大另外一个，游戏速度，马里奥都跑出屏幕了。

假设你想设计一关，马里奥跳过一只乌龟就可以让它成为一个小的通道。游戏程序员通常用两步来解决这一的问题：首先，看着你的代码，控制马里奥跳多高的代码，他能跑多快，乌龟的背有多高，然后再编辑器里做一些调整，用你的想象力来预测一下我们做出来最终的效果是怎么样的。然后你就可以重新玩这个游戏看他实际是什么样的。

Victor 想要一些更直接的东西。他引用马里奥这关的路线来说：“如果你有一个及时的过程，你想即时看到修改的结果，你就需要把时间映射到空间上去。”他敲了一个按钮不是现在马里奥要显示的地方，而是未来要显示的地方：马里奥被拉到很远地方的影子。而且，这个投影路径是被动的：当Victor改变游戏的参数，现在是通过鼠标的快速拖动来控制，路径的形状就会改变。这就像拥有一个上帝视角一样。整个问题就简化成了几个参数的游戏，好像调整立体声接收器上的值，除非你让马里奥去完成艰巨的任务。有了正确的接口，就像你不用写代码就可以工作了；你直接控制着游戏的行为。

当观众第一眼看到这一幕时，他们简直喘不上气来，震惊了。他们知道他们看得不是一个小孩子的游戏，而是整个工业的未来。大多数软件所涉及的复杂的行为，随着时间的推移，Victor已经表明，如果你有足够的想象力，你可以开发出所见即所得，好像玩弄于你的鼓掌中。一个看了这个演讲的程序员后边写道：“突然我觉得我所有的工具都过时了。”

当John resig看了这个演讲，他放弃了Khan学院的编程课程计划。他希望网站的编程练习能像Victor的演示一样起作用。左手边你已经完成了编码，右手边就可以运行程序：一个图片或者游戏或者模拟。如果你修改了代码，它就立刻改变图片。关于这种方式Resig写道：“在这种真实的响应似的环境中，你可以完全修改学生学习的模型…他们可以即可看到结果，直观地看底层系统本质上是如何工作的，而不需要明确的解释。”Khan学院已经成为世界上最大的计算机编程课程，每个月平均有一百万学生在使用这个程序。

Chris Granger在微软的Visual Studio项目中工作，也受到了启发。看恶劣Victor的视频几天内，2012年1月份，他创建了一个新的编程环境的原型。他关键的能力是它可以给你程序实时的行为反馈。你可以看到系统在控制它的代码下正在做的事情。这就像取下了眼罩。Granger把这个项目称作“Light Table”。

2012年4月，他为Light Table在Kickstarter寻找资金。在编程圈这成了一个轰动。不到一个月的时间，这个项目就募集了超过200000美元的资金。这个思想就扩散开了。这种实况的表现方式，能够实时的看到程序里的数据流，进入了Google和苹果的旗舰软件。制作新的iPhone和Mac应用程序（称为Swift）的默认语言是由苹果公司从底层开始开发，用于支持由Light Table启发下开发的环境，称作游乐场。

但是看了他的演讲后所带来的影响，Bret Victor却大失所望。他后边说：“很多事情好像曲解我说的话。”当人们开始邀请他参加会议讨论编程工具时，他知道出现问题了。他说：“所有人都认为我对编程环境感兴趣。”正如他在《动态行为视觉表现》中所说的，他对人们如何看待和理解系统很感兴趣。尽管代码越来越成为创建动态行为的选择，但是它仍然是最难以理解的工具之一。“创造准则”的关键是展示了你可以通过创建系统的行为和它代码的直接联系来减轻问题。

我不确定编程是否还会存在

在接下来的两个演讲中，“停止画死鱼”和“画动态的可视化”又更近了一步。他展示了两个他开发的程序，一个是给动画制作人的，另一个是给那些想要可视化数据的科学家的，每个都采用了一个涉及了大量自己编码的过程，并将其减少到了所见即所得的界面中。Victor建议到同样的办法在现在编码的早期可以被使用来处理每个问题。他告诉我：“我不确定编程是否还会存在，或者软件开发人员是否还会存在。”在他的思想里，一个软件开发者正确的角色是创造可以消除软件开发者需求的工具。只有这样，那些最迫切需要解决计算问题的人才能直接抓住这些问题，而不需要任何的中间代码。

当然要做到这点，你必须让程序员们自己先做到。最近的一篇文章中，Victor呼吁那些专业的软件开发者不要再浪费他们的天赋在开发相Snapchat或者Uber这样的app上了。他写到：“日常生活的不方便不是太大的问题。”相反，他们应该把注意力专注在科学家和工程师上，正如他们对我说的那样，“这些真正做工作的，解决实际问题，重要问题的人，他们正用着很糟糕，很糟糕的工具。” 他写道，已经有这么多的令人兴奋的工作，特别是一些用于“基于模型的设计”的工具，但大多数程序员都不了解它们。

“如果你仔细观察你所使用的所有工业产品，你正在使用的，或者那些公司正在使用的，唯一非工业化的产品就是代码。”Eric Bantégnie是Esterel Technologies 的创始人，一个法国的公司为构建安全重要的软件开发工具。像Victor和Bantégnie不认为工程师应该在IDE里敲几百万行代码来开发大型系统。他说：“没有人会用手来打造一辆汽车，代码在很多地方仍然是手工的。当你手工的写10000行代码时还可以接受。但是你这个系统有3000万行代码，像空客或者10亿行代码的特斯拉，或者高档车都变得非常非常的复杂。”

Bantégnie的公在工业界司是使用基于模型设计的先锋之一，在这里你可以不用再写代码。取而代之的是你创建一个流程图用于描述你程序应该遵循的规则，计算机则根据你的规则生成代码。例如，如果你给一个电梯的开发控制系统一条规则就是当电梯的门是打开时，如果有人按了大堂的按钮，电梯就会关门，然后运行电梯。在基于模型的设计工具里，你可以用一个小的图来表示这个规则，因为通过在白板上画出逻辑图，不同的状态由不同的盒子，例如：门打开，运行和门关闭。线条则表示你怎么从一个状态转换到另外一个状态。这个图就让这个系统的图变得很清晰：仅通过看这个图就可以知道让电梯运行的唯一通路就是关闭电梯门，或者唯一让电梯门打开的办法就是让电梯停下来。

人们知道怎么写代码，问题是写什么

这不是很Photoshop。Photoshop的美丽之处当然是最终展示在屏幕上的图片。通过对比在基于模型的设计下。你屏幕上的图片更像是一个蓝图。而且用这种方式来开发软件性质上和传统编程方式是不同的。在传统的编程里，你的任务就是找出复杂的规则然后把它们翻译成代码；你大多数的精力都被花在了翻译成代码上，而不是思考规则本身。对基于模型的这种办法来说，你只需关注的就是规则。所以这才是你需要花时间来思考的。这是一种解决问题的方式就是把更多的精力集中在问题本身上而不是机器上。

“我也是一位程序员。通常，软件编码的主要问题不是程序员的能力本身。人们知道怎么写代码。问题是写什么代码。因为大多数的需求都是自然语言，含糊的，同时需求是绝对不会描述的很准确的，它通常被程序员错误的理解。”

在这样的观点下，软件变得不守规矩因为用于描述软件应该做什么的媒介，交流，散文似的描述，在一张纸上画出来，都和软件应该做什么差异很大。从一个到另一个丢失的信息有很多。在基于模型设计的背后的理念就是缩小差距。这很类似的模型同时被系统设计师来表达他们需要什么，和计算机自动生成代码。

当然，为了取得成功，这项工作在项目开始前必须做好很多工作。首先必须有人构建一个用来开发对人们来说很自然的工具，这些工具就像是在记笔记或者画他们已经想好的东西一样，但是对于计算机来说就没有那么模糊不清了。他们不得不做一个程序把这些模型转化成实际的代码。最后他们不得不证明生成的代码会和预期的一样正确运行。Bantégnie ：“幸运的是我们已经受益于20年的初步的背后工作。”

Esterel科技，2012年被ANSYS收购，从法国核工业和航空航天工业开始的20世纪80年代开始，他们担心重要安全代码的复杂性越来越高，越来越难以避免错误。Emmanuel Ledinot，Dassault航空的科学研究主管，法国战斗机和商用飞机制造商说：“我从1988年就开始了，那个时候我正在做军用航空电子系统。负责集成系统，调试他们的人已经注意到bug数量在上升。” 80年代飞机上的机载电脑数量激增。不是单一的机载电脑，而是有几十个，每个负责与控制，导航和通信相关的高度专业化的任务。协调这些系统来驾驶飞机因为从传感器输入的数据，并且当飞行员输入命令时需要完美的及时的反应。“正确的顺序处理这些成百上千的事件，而且在正确的时间，是故障增多的主要诱因。”

Ledinot认为用手写这样复杂的代码已经变得不可持续了。理解它在做什么实在是很困难，同时也不可能验证它是否正确工作。他就去寻找新的办法。他在这个演讲中说：“你必须明白，在这样的过程中，更换工具是非常昂贵的，你不会采取这个决定出发你已经走投无路了。”

大多数程序员喜欢代码。至少他们理解了

他开始和Gerard Berry，法国计算研究中心的一位INRIA的计算机科学家，在一个叫作Esterel的工具上进行合作，一个法国实时混成的工具。Esterel背后的思想当传统的编程语言可能适合描述简单的过程，这些都是以可预测的顺序发生，例如一个食谱，如果你想在一个系统中使用它，同时很多事件在任意时刻都可能发生，还以任意的顺序，就像在飞机的驾驶舱里，你不可避免的弄的一团糟。但是在控制软件中如果一团糟的话就会很危险。在一篇论文中， Berry甚至预言，低级别的编程技术不会被大型的安全为重的程序所接受，因为它们让行为理解和分析几乎行不通。”

Esterel被设计来让计算机给你处理这种复杂问题。这就是基于模型方法的前景：代替编写简单的编程代码，你创建了一个系统行为的模型，在这种情况下，一个模型关注于如何处理单个事件，如何对事件进行优先级排序，哪些事件取决于其他事件，等等。该模型成为计算机用来进行实际编程的详细蓝图。

Ledinot和Berry一起工作了接近10年时间，让Esterel可以达到生产的程度。Ledinot告诉我：“这是在2012年，我们拥有了第一个具有自动代码生成的可操作的软件建模环境。第一个嵌入的模块是在阵风这款战斗机上。”今天，ANSYS的安全为重的应用开发环境产品被用来生成用于航空和国防行业的公司代码生成、核电站、交通系统、重工业和医疗设备。 Bantégnie ，Esterel 科技的创始人说：“我最初的梦想是让安全为中的代码开发环境生成的代码被用在世界上的每一个飞机上。现在我们离那个目标已经不是很远了。”几乎空客A380上所有的安全为重的代码，包括控制飞机飞行表明的系统都是由这个产品生成的代码。

特别是航空业的客户的很大一部分是可以用手工的方式来创建高可靠性的软件的，但是这可能是一项艰巨的任务。Ravi Shivappa，一家在Meggitt PLC的软件公司的副总裁，一个ANSYS的客户，他们为飞机构建模块，比如发动机起火探测器，就可以说明传统的项目一开始都有很多的英文写的需求文档，里边指出了软件应该做什么。（一个需求文件可能类似：“除非手动重写开关打开，当这个部分的压力超过阈值时，打开安全阀。”）用这种方式描述需求的问题是，当你在代码中实现这些需求时，你必须仔细检查每一个是否满足。当客户更改需求时，代码也必须进行更改，并进行广泛的测试，以确保流程中没有其他内容被破坏。

严格的监管标准使成本更加复杂。联邦航空局对软件安全非常在意。该机构规定，对安全为重点的软件的每一项要求都可以追溯到实现它的代码行，反之亦然。所以每次一行代码的变化，它必须追溯到在设计文件中相应的要求，你必须能够证明代码满足这个要求。这个想法就是，如果出了什么问题，你就能找出原因；这个实践带来了秩序和责任更大的代码库。但是，Shivappa说：“这是一个劳动密集型的过程。”他估计在他们使用基于模型的设计前，在一个两年的项目里，只有两到三个月的时间用于写代码，剩下的时间用来理解需求文档。

我们已经知道如何让复杂的软件可靠，但还有这么多的地方，我们没有选择

正如 Bantégnie 解释的，让一台电脑来让你需求转化为代码而不是由人来实施的魅力是你能够确定，实际上你可以从数学上证明，生成的代码是满足需求的。基于模型的方法的许多好处，它能够及时添加需求，同时确保现有的需求得到满足；每一次更改，计算机都可以确认你的程序仍然有效。你可以自由调整你的蓝图，而不必担心引入新的问题。用FAA的说法就是，你的代码“通过施工来纠正。”

同时，大多数的软件，尽管如此，大多数软件甚至在安全的航空世界中都是以老式的方式进行的，工程师们随意的编写需求文档，编程人员则用C语言编写代码。正如 Bret Victor 在论文里澄清的，基于模型的设计相对来说是不常见的。Shivappa 告诉我：“很多在 FAA 的人认为生成代码是很神奇的，因此需要更多的审查。”

大多数的程序员都有同样的感受。他们喜欢编码。至少他们理解它。为你写代码的工具，用 “有限自动机”和“循环系统”听起来很深奥，很难使用，如果不太好就不是真的了。

这是一种在以前发挥过作用的模式。不管编程是否已经脱离写文字的 1 和 0 的时候，最强烈的反对的声音来自于程序员那里。Margaret Hamilton 一位参与了阿波罗计划的著名软件工程师，事实上是“软件工程”的创造者，告诉我，1964 年当她在 MIT 的 Draper 实验室期间，她记得有一个会议，一个派系正在和另外一个派系进行争论，讨论如何脱离“非常低级的机器语言”非常接近 1 和 0 的语言到“汇编语言”。“在最底层的开发者在极力争取保留它。争论都很类似：“我们怎么知道汇编语言会做正确的事情呢？”

她说：“另一边，他们的脸变红了，他们开始尖叫起来。”她很惊讶他们有多激动。

可以做你想做的所有测试，但你永远也找不出所有的错误

Dassault 航空的 Emmanuel Ledinot 指出当汇编语言本身逐渐被淘汰，以支持今天仍然流行的比如 C 语言，正是汇编程序员们对此持怀疑态度。难怪他说：“人们不是那么简单的过度到基于模型的软件开发：他们认为这是另一个失去控制的机会，甚至超过了他们已经控制的。”

对基于模型的设计的偏见，有时被称为模型驱动工程或者 MDE，根据最近的论文来说是如此的根深蒂固，“有些人甚至认为，我们更需要研究人对 MDE 的观念而不是研究新的 MDE 技术。”

这听起来像是一个笑话，但对于基于模型的方法的支持者来说，这是一个重要的问题：我们已经知道如何使复杂的软件变得可靠，但在许多地方，我们却没有选择这种方法。这是为什么呢？

2011 年 Chris Newcombe 在 Amazon 已经 工作了很多年，已经晋升到了首席工程师。他曾经参与过公司里有一些重要系统的开发，包括零售产品分类和控制世界上每台 Kindle 设备的基础设施。他是 Amazon 网络服务最有价值团队的领导，这个团队维护了网络的最大网站：Netflix，Pinterest，和 Reddit。在 Amazon 之前，他还帮助构建了 Steam 的后端，世界上最大的在线游戏服务。他是那些默默的工作，让网络运行的工程师之一。他开发过的产品被认为是巨大的成功。但是所有他想到的是那些深埋在这些系统设计里等待着发生的灾难。

他在一篇论文中写到：“人类的直觉很难估计这些每秒百万级别请求的系统中极端情况发生的概率。人类的不可靠意味着一些更微妙的，危险的细菌可能会在设计上出现错误；代码忠实的实现了设计的预期，但是设计却未能正确的处理那些极端的场景情况。”

Newcombe 确信真正关键的是系统背后的算法，不能应该还好，而是应该完美，例如存储网络数据重要部分的系统。一个细微的问题就可能带来灾难。但是他知道错误是多么的难以发现，尤其是当算法变得越来越复杂的时候。你可以做所有你想做的测试，但是你就是永远也找不到他们。

很少有程序员会在编码前列出程序的具体功能

这就是为什么他那么感兴趣的时候，在他阅读一篇论文的附录的时候，他忽然遇到一个奇怪的数学和代码混一起的表达式，以“TLA+”方式描述的算法。令人惊讶的是，这种描述在数学上是精确的：一个以 TLA+ 方式来写的算法在原则上可以被证明是正确的。实际上，它允许你创建一个现实的问题模型，并对它进行全面而彻底的检验。这正是他一直在寻找的：一种用于编写完美算法的语言。

TLA+ 是“Temporal Logic of Actions”的缩写和基于模型的设计思想很类似：就是一个用来写计算机软件程序需求的语言，TLA+ 把它们称作“规格”。这些规格接下来会被计算机完整的验证。这是在你写任何代码之前，你写了一个程序的简洁的轮廓，和一些需要满足的限制（举例说：如果你正在编程一个 ATM 程序，一个约束可能是你永远不能从你的支票帐户两次提取相同的钱）。然后，TLA+ 会彻底检查你的逻辑是否满足了这些限制。如果不满足，它会给你显示出他们是为什么验证失败的。

这个语言是由图灵奖获得者计算机科学家 Leslie Lamport 发明的。一个白色的大胡子和邋遢的白头发，和大眼镜后面的慈祥的眼睛，Lamport 看起来他可能是在美国霍格沃茨的一个友好的教授。现在在微软研究中心，他是“分布式系统”理论的先驱之一，这个理论描述了有多个部分组成的计算机相互通信。Lamport 的工作为现代网络的建立奠定了基础。

对于 Lamport 来说，今天的软件充满了 bug 的主要原因就是因为编程人员直接编写代码。他在文章中写到：“建筑师在布置砖或钉子之前会画出详细的计划，但是没有程序员会在他们开始编码之前写下一个甚至是比较粗略的程序草稿。” 程序员被编码的重要性吸引了，因为代码才能让程序运行起来；花时间在别的地方看起来会让人分心。同时从微观的代码中可以得到一个病态的喜好，一种臆想出来的满足。但是 Lamport 争论到，代码从来就不是一个思考的介质。他说：“当你以编程语言的角度来思考时，它确实会限制你思考的能力。”代码让你错过了森林中的大树：它吸引了你关注个人工作，而不是你的程序如何配合在一起的创造更大的成功，或者它应该做什么，以及它是否真的做了你想要他做的。这就是 Lamport 发明 TLA+ 的原因。因为有了基于模型的设计，TLA+ 让你把注意力集中到系统的上层架构上，它的基本逻辑，而不是实现它的代码。

Newcombe 和他在 Amazon 的同事会用 TLA+ 来发现微小但是很严重的 bug，包括在 S3 背后的核心代码，被认为是世界上最可靠的存储引擎。现在它在公司里被广泛使用。在曾经使用 TLA+ 的微小圈子中，他们的成功并不是那么的不同寻常。Microsoft 的实习生使用 TLA+ 来捕获可能导致世界上所有 Xbox 在使用四小时后崩溃的错误。欧洲航天局的工程师用它来重写了代码，一下子减少了 10 倍的代码量，这些代码是用在首次在彗星上着陆的探测器上操作系统中的代码。英特尔定期使用它来验证他们的芯片。

但是 TLA+ 的占有率很小，在离大流远远的角落里，如果说可以占据空间的话。即使对于一个经验丰富的工程师语言也首先被看作是奇异且深奥的符号动物园。对于 Lamport 来说，这是教育的失败。虽然编程是在数学中诞生的，但它已经在很大程度上脱离了数学。大多数的程序员对逻辑数学，集合理论都不是很熟悉，这些在 TLA+ 中都需要用到。Lamport 说：“很少的程序员，包括部分编程的老师，都不知道怎么把基础理论运用到实践中去。他们认为他们需要的就只是写代码。比代码更高层次的东西需要你能够准确的思考的这种思想，这完全是外来的，数学就能让你可以准确的思考。因为他们从来都没有听过它。”

如果他们不明白这些简单的事情，我希望人们不会被允许去写代码

简而言之，Lamport 将数学化的失败看成是现代软件开发的问题：风险持续上升，但程序员并没有进步，他们还没有开发出能处理日益复杂的问题所需的软件。 他说：“在 15 世纪，人们过去不知道微积分就建造大教堂，现在我不认为你会允许任何人在不知道微积分的情况下就开始建造大教堂。我希望在一段很长的适当时间过后后，如果不明白这些简单的事情，人们就不会被允许去写代码。”

Newcombe 不太确定是否是程序员应该被指责。“我听 Leslie 说，程序员很畏惧数学。我发现程序员不清楚，或者说不相信，数学可以帮助他们来处理这些复杂的情况。复杂性对于程序员来说是最大的挑战了。”让人们使用 TLA+ 最真正的问题是说服他们这不是在浪费他们的时间。程序员作为一个职业，他们是务实的。像 TLA+ 这样的工具散发着象牙塔一样的味道。当程序员遇到“形式化方法”时（这样叫是因为他们设计数学，“形式化”准确的描述了程序），他们的本能是退缩。

大多数的程序员在大学都学了计算机科学都对形式化的方法有初步的认识。通常它们会在一些细小的事情上表现出来，比如从零开始计数的程序；学生的工作就是从数学上证明程序实际上是从零开始计数的。

Newcombe 表示：“我需要改变人们对形式化方法的看法。”甚至 Lamport 似乎自己也并没有完全掌握这一点：形式化方法存在图像问题。解决问题的方法不是请求程序员改变，而是改变自己。Newcombe 意识到，把像 TLA+ 这样的工具带到编程的主流，你需要说他们的语言。

曾经当他在亚马逊向他的同事们介绍 TLA+ 时，他会避免告诉他们现在的是什么，因为他害怕这个名字让它看起来令人生畏：“行为时序逻辑”在学术界有很好的表现，但是推迟了大多数的初级程序员。他还试图不使用“正式”、“验证”或“证明”等术语，这会暗示程序员冗长的课堂练习。相反，他提出 TLA+ 是一种新的“伪类”，到达真正的代码的一块阶梯，能让你彻底地测试你的算法，让你的在设计过程早期能准确的思考。他写道：“工程师从调试而不是“验证”的方面来思考，所以他就亚马逊工程师的“调试设计”这个题目进行了内部的讨论，而不是嘲笑程序员在代码中看世界的事实，Newcombe 同意了这个观点。他知道不这样的话他会失去他们。

代码创建了一个全新的复杂度，且它也会导致失败

他已经离开 Amazon 然后去了 Oracle，这里他能够说服他的同事尝试 TLA+。对他来说，使用这些工具现在是一个责任。他说：“我们需要在这方面做得更好。”

“我是自学的，9 岁就开始写代码，所以我的本能就是写代码。那是我唯一的思维的方式。”在他看来，这是今天许多程序员仍在做的。“如 Google 工程师，他们在 Stack Overflow 上查问题并且他们获得代码片段来解决这个小功能中的问题，并将它们调试在一起，并进行迭代开发。”

“这完全可以，直到你遇到一个真正的问题。”

在 2015 年夏天，一对美国安全研究人员 Charlie Miller 和 Chris Valasek 确信汽车制造商没有认真对待汽车中的软件缺陷，同时还表明 2014 年款的吉普切诺基可以被黑客远程控制。他们利用了汽车的娱乐系统，即具有蜂窝网络（因为这样你才能通过 iPhone 来启动你的汽车）链接到了更多的中央系统，如控制挡风玻璃雨刮器、转向、加速和制动。

虽然他们没有真正写一个病毒但他们也证明了是可以写出一个聪明的软件——汽车蠕虫，它可以使用在汽车的电脑上来黑掉吉普的切诺基然后扫描周围，再黑掉其他的车；只要他们想，他们可以同时进入全国范围攻击。

Valasek 表示：“我们需要对软件进行不同的思考。”汽车公司早就把由数百个不同供应商制造的零件组装成自己的最终产品。但是，这些部件曾经是纯粹机械，现在，它们通常都有数以百万行的代码。虽然这些自适应巡航控制的代码，汽车刹车和车道辅助确实使汽车更安全。但它还创造了一种全新的复杂性。它让一种新的失败成为可能。

在自驾车的世界里，软件不可能来马后炮

Gerard Berry，法国 Esterel 的研究员在演讲中表示：“汽车里有很多 Bug，它不像航空电子设备那样受到非常高的重视。同时软件的机制也不相同。” 汽车行业也许还没有意识到他们实际上也在做软件业务。

参与了测试丰田案子的软件专家 Michael Barr 说：“在汽车制造行业，我们没有软件安全监管机构来控制做什么。”他说：“美国高速公路安全管理局只有有限的软件专业知识。他们从机械时代走来。” 同样的监管压力使得基于模型的设计和代码生成对航空业很有吸引力，但汽车制造业的进展却比较慢。Dassault 航空的 Emmanuel Ledinot 推测是因为经济原因才导致了差异。汽车制造商不能简单的增加一个部件的价格，甚至是几毛钱也不行，因为它增加了百万倍；嵌入汽车的电脑必须精简到最低限度，还没有足够的空间来运行尚未被手动调整到足够简洁的代码。“我认为介绍基于模型的软件开发在过去十年中对他们来说太昂贵了。”

但是有可能会发生改变。Ledinot 告诉我：“我认为自动驾驶车辆可能会推动他们。ISO 26262和无人驾驶汽车可能会慢慢地促使他们在关键部件上采用这种方法。”（ISO 26262 是 2011 出版的汽车安全标准。）Barr 也说了也差不多事情：在自驾车的世界里，软件不可能来马后炮。它不能像今天的航空订票系统或 911 个系统或股票交易系统那样建立起来。代码将负责道路上数亿人的生命，它必须管用。这不是一个小任务。

Gerard Berry 在演讲中表示：“计算本质上是看不见的，当你的轮胎扁了，你看轮胎，扁了。 当你的软件坏了，你看看你的软件，你什么也看不见。”

“所以这是一个艰巨的任务。”

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！