软件系统复杂性灾难及解决方案探究

软件系统复杂性灾难及解决方案探究

一、What is complex

在谈论复杂性灾难极其解决方案之前，我们首先来理解一下“复杂”这个词。
什么是“复杂”呢？对应的英文单词complex的释义能很好的表达软件工程中涉及到的复杂性。

根据权威的牛津词典，complex的释义为：

made of many different things or parts that are connected; difficult to understand

可以看到complex有三层基本含义，首先是由多个部分或事物组成，其次这些部分之间是有相互关联的；再次，整体不便于理解。

复杂性，是人类社会高速发展的必然产物。过去200年的现代化过程，复杂性是个常见的事情，人类社会总是趋向于越来越复杂。就拿机器来说，从最早的几十个零件，到几百几千几万个零件。一架波音747飞机上面，有600万个零件，275公里长的的各种管线。世界上没有任何一个人能彻底搞得清楚一架波音747飞机的完整构造。

但是作为应对，人类也演化出来了一个处理这种复杂系统的方法，简单来说就是模块化加上分层协作。每个人只负责其中的一个模块，然后层层叠加，构成一个庞大的系统。出了问题也不怕，层层分解，也能找到问题所在。所以，即使像芯片那么复杂的东西，上面集成了数以亿计的晶体管，人类还是可以设计它，制造它和控制它。复杂性看起来没有特别可怕；波音747的可靠性可能要比大多数APP高得多，平均每百万次航班出现1.62次死亡事故；而世界上安全性最高的飞机每百万次航班出现死亡事故0.33次。

二、The Disaster

我们再来看几个数字。2015年，谷歌公司统计了自家所有产品的代码，加起来20亿行。2018年，阿里巴巴公司的程序员，一年写下了12亿行代码。而2020年华为的绝版芯片，5nm工艺的麒麟9000，内含晶体管数量有153亿个。
听起来仿佛也还好吧？大型软件公司的代码行数，和一个芯片上的晶体管数量，在量级上相差无几。所以一个芯片我们人类可以控制，那软件我们人类是不是也可以很容易的控制呢？答案是否定的，它们的复杂性完全不一样。

作为业内崩溃率控制比较优秀的产品，**APP的crash率在万分之2左右；日常也有很多非常多的各类bug。如果是崩溃率稍微差一点的产品，崩溃率可能会更高，日常使用中各种bug更是随处可见。
原因是什么呢？各位看官可以花一分钟的时间思考一下。

《为什么需要生物学思维》这本书里说，一堆东西放在那里，即使很多，很乱，那叫“庞杂”。但是一堆东西，到了一定数量，之间还互相影响，发生“级联效应”，那就叫“复杂”。一旦达到这样的复杂程度，将成为一个无法控制的，甚至是无法理解的系统，我们可以称之为“复杂性灾难”。

物理设备、模块之间的边界比较清晰，相互作用比较明确。而代码和代码之间是要发生各种各样的互相影响的，还会有“级联效应”。几百万行，甚至十几亿行的代码，一旦发生互相之间的关联互动，而且是一层一层的不同级别的互动，产生的情况有多少种呢？可能比整个宇宙的粒子数量还要多。

所以你看，过去机械时代的工程师形象是很严谨的。他们干的活儿是绘制蓝图、按图施工、精确控制、准确无误。当他们造出了一个机械系统，不管多复杂，他们就是这个系统的神。但是今天的软件工程师呢？虽然这个系统是我们一行行写的，也是我们造出来的，但我们远远不是这个系统的神。总有一些我们控制不住的东西，比如我们一辈子都要和bug打交道。永远不可能把它们彻底消除。不是软件工程师不优秀，而是bug实在太狡猾。

这是一个很深刻的变化。

举个例子，1986年1月，美国挑战者号航天飞机升空爆炸。不到一个月后，著名物理学家费曼就提交了一份报告，说出事的原因分析出来了，是因为一个密封圈出了问题。虽然也很难，需要费曼这样大神级的物理学家才能分析出来，但是毕竟最后罪魁祸首找到了。
但是10年后，1996年，欧洲阿丽亚娜火箭在发射升空后爆炸。为什么呢？只有一个模糊的原因，说火箭在新环境下使用了一些较为陈旧的软件代码。但是，没有任何一个承包商被追责。因为这次爆炸并不是某个决策失误导致的，找不到挑战者号密封圈的那样的东西。整个发射系统的极度复杂，带来了这样的灾难。
再过10年，2007年，丰田汽车在美国出了一个重大事故，车子在行驶中突然加速，刹车失灵，最后致人死亡。这件事当时闹得很大。事后，丰田请来专家调查原因。查来查去，发现是软件的原因。说到底，是因为丰田发动机软件系统过度庞大、极度复杂，没有办法把事故责任明确地归咎于某个