泰安APP开发:软件完*按照我们的指示行事。软件失败的原因在于我们告诉它做了错误的事情。
关于工程失败我们标准的思维框架是在二战后不久形成的(在软件出现之前,针对机电系统)。其想法是通过把部件做得可靠(比如引擎可承受40000次起飞与降落周期)以及为那些部件故障做好预案(准备2个引擎)来把东西做得可靠。但软件不会坏掉。Intrado的错误阈值不像导致飞机失事的缺损铆钉。软件完*是按照人的吩咐行事的。实际上软件执行得非常完美。它失败的原因在于它被告诉做了错误的事。软件失败是理解的失败以及想象的失败。Intrado其实是有个备份的路由器的,如果能自动切换过去的话,几乎**能恢复911服务。但“当时发生的情况是应用逻辑并没有要执行自动修正行动。”
这*是通过代码而不是实体做东西的麻烦。如Leveson总结那样:“复杂性是肉眼看不见的。”
现在正在进行的改变软件制作方式的尝试似乎都始于同*个前提:代码实在是太难琢磨了。那么在试图理解这些尝试之前,弄清楚为什么会这样是值得的:是什么让代码对大脑那么陌生,跟之前的东西那么不*样呢?
技术进步往往会改变世界的样子——你可以看着道路铺设下去,你可以看到天际线的崛起。但在今天你很难说出什么东西进行着了再造,因为这些东西经常是由代码重构的。比方说,当你踩了汽车油门时,你不再直接控制任何东西;脚踏板与风门之间并没有机械连接。相反,你只是给软件提交了*条命令,给引擎补充多少空气是由后者决定的。汽车*是你可以坐进去的计算机。方向盘和踏板*样可以是键盘的按键。
跟*切其他东西*样,汽车也被计算化以促进新功能。当*个程序负责风门和刹车时,在你距离另*辆车太近时它可以放慢车速,或者控制燃油喷射来帮助你省油。当它控制转向器时,它可以在你开始漂移时保持在自己车道内,或者引导你进入停车区。没有代码你实现不了这些功能。你可以试试,没有代码的汽车*会变成庞大的、重达40000磅但无法移动的发条装置。
软件让我们做出了有史以来*复杂的机器。但是我们几乎都没注意到,因为所有的复杂性都被包裹进小小的芯片里面以及数百万行的代码之中。但仅仅因为我们看不见复杂性并不意味着它*没有了。
*的荷兰计算机科学家Edsger Dijkstra在1988年曾经写到:“必须思考*个头脑此前从未面临过的概念层级。” Dijkstra把这当成*种警示。随着程序员热切地想要把软件植入到关键系统当中,软件日益成为建造世界的关键——Dijkstra认为他们已经高估了自己。