为什么软件总是不靠谱

本文作者：张海龙，CODING 创始人兼 CEO。技术创业者，十多年来一直在技术圈、开发工具领域耕耘， 2014 年创办 CODING ，给企业用户全套 DevOps 研发管理工具，包括项目管理、代码托管、持续集成、制品管理、持续部署，让整个开发过程都可以在浏览器中实现。

前段时间里去看了信条，电影里，诺兰把算法具像化了，搞了九个铁块拼接在一起，调用方式是核爆炸，挺形象的。

事实上这个世界确实是由算法组成的。你去医院看病，从预约到挂号到检查开单拿药都是标准流程，也就是医院的算法。对于大型综合性医院来讲，这套算法都是一样的，算法上每个环节是由哪个人来完成实际上并不重要（目前而言，主治医生还是很重要，但早晚也不重要），只要是按照这个算法来，你的病大概率能被治好。

同样的例子还有建筑行业，具体哪个工程队负责实施其实并不重要，按照既定的算法去盖房子，极大概率不会塌掉。建筑开发商也不会为某一栋房子安排工程人员的 24 小时 on-call 以应对随时可能发生的事故。

虽然算法这个词语来源于计算机（我没有去考究，但我相信大多数人跟我一样这么认为），然而讽刺的是软件工程却没有一套可靠的算法。目前软件系统的可靠性相比其他行业是要低的多的。我们经常性会发现某个应用挂掉了，习以为常。但如果哪天哪栋房子塌掉了，那一定是大新闻。

事实上目前并没有一个通用的算法来从零开始生产出一款软件。每个 CTO 都有自己的算法，不同的技术不同的流程不同的工具（虽然有 CMM 这样的标准，但事实实践范围很小，而且效果也一般）。这就导致了一个问题，软件行业的可靠性极大的依赖具体开发的人。然而人是不可靠的，所以软件行业的可靠性令人堪忧。这还导致了另外一个问题就是人员流动的效率。A 公司的程序员跳槽去 B 公司，就要适应新的技术流程和工具，两周到一个月的适应期是起码的。

我经常从高处俯瞰深圳密密麻麻的工地，一座座的塔吊矗立在那里，一台台的叉车川流不息。作为基建狂魔的中国，如果这些塔吊和叉车不是标准化的，如果中建三局和中铁四局的作业流程不是标准化的，我们如何在短短的四十年时间组织上亿的农民工兄弟完成如此多的基建项目。

现在讲新基建，也就是数字化基建。在整个人类社会数字化的大趋势下，这看起来像是全人类的大事。然而我们目前软件工程的可靠性真的准备好了吗？我们是不是经常面临软件项目的延期？我们是不是经常认为过去的项目需要推倒重来？我们是不是每天都在担忧哪栋数字化的大楼会突然塌掉？今年突如其来的新冠疫情使得各地都要紧急上马健康码项目。各大厂商也是抽调人力来紧急支援。然而实际的过程却是一团乱麻，管理者四处救火，一线开发天天加班却产出有限，实施方换了几波也没有很好的解决问题，以至于某东北大省的省长直接给某大厂一把手打电话施加压力。

数字化的渗透越来越深，软件系统的故障影响的就是民生。这个问题一定会引起行业的重视。可幸的是，云计算的普及极有可能开创软件工程的标准化时代。类似于工业时代统一度量衡，统一螺丝螺母的规格，类似于当年秦国车同轨书同文。

当所有的应用都运行在云上以后，运行的环境，依赖的组件，甚至这些环境和组件的管理方式都是相同的。这就给软件开发过程的工具和流程标准化提供了基础。并且，应用上云以后，应用开发过程上云也是迟早的事情。整个开发过程云端化，数字化以后就为软件工程的度量奠定了基础。我们终于有了量化的手段来有效的衡量软件开发人员的产出。这也是我认为软件工程行业迈向成熟的关键一步。

虽然我们还不能清晰的描绘这个软件工程的算法具体长啥样，但我们可以看到在云计算的推动下这个框架已经在形成。我相信有一天开发人员不用为每个项目学习新的流程和工具，我们也不用整天担心自己开发的系统会不会突然挂掉。