原来COBOL程序与Debug还有这段历史

上周，网上有不少新闻说美国新泽西州的州长在新闻发布会上招聘COBOL程序员的事。新闻里说，由于COBOL程序是一个很老的程序，古老到它的使用者绝大部分都是老年程序员，于是看到不少人拿这件事调侃。

我去查了查资料，发现这个确实是在美国真实发生的事情，在冠状病毒大流行之后，新泽西州充斥着失业救济申请。而新泽西州的数据处理系统正是基于COBOL搭建的，这个系统已经有40多年的历史，但很显然，系统在这次冠状病毒过程中还没有准备好。

另外，还查到一个比较有历史的故事，我们现在编程都知道Debug，但这个Debug其实和COBOL有着千丝万缕的关系。

1、COBOL程序介绍

COBOL（Common Business Oriented Language，面向常规商业信息处理语言）是一种面向数据处理的、面向文件的、面向过程的高级编程语言，适用于具有循环处理的场合以及数据操作量相当大的环境。COBOL主要应用于商业数据处理领域，对各种类型的数据进行收集、存储、传送、分类、排序、计算及打印报表、输出图像等是它的强项。

COBOL是1959年制定的标准，并于1961年由美国数据系统语言协会公布，正式发布于1960年4月，称为Cobol-60，现在稳定的版本是ISO/IEC 1989:2014（2014）。（1*）

资料显示，是美国的格蕾丝·穆雷·赫柏（Grace Murray Hopper）博士于1959年领导的一个委员会，制定了COBOL语言标准。这个格蕾丝·穆雷·赫柏是世界最早一批的程序员之一，也是最早的女性程序员之一。她是Harvard Mark I上第一个专职程序员，创造了现代第一个编译器A-0系统，被誉为“COBOL之母”。（*2）

2、COBOL与Debug的关系

1947年9月9日，格蕾丝·赫柏和他的团队第一次提出了“电脑Bug”这个概念。当时他们在Harvard Mark II计算机上工作时，电脑不知道为什么不能正常工作了。经过赫柏的深度挖掘，发现原来是一只飞蛾意外飞入了一台电脑的内部继电器中造成短路而引起的故障。团队把错误解除了，并在日记本中记录下了这一事件。从这以后，程序届开始用“Bug”（原意为“虫子”）来称呼计算机中隐藏的错误。

美国海军历史中心在线图书馆照片

在这之后，受到从电脑中驱除飞蛾虫子的启发，计算机术语“Debug”（调试排错）开始使用，于是格蕾丝·赫柏也被誉为“Debug之母”的称号。她是美军第一个获得海军准将（位于少将和上校之间）头衔的女性，美国海军驱逐舰USS Hopper（DDG-70）便是以她来命名的，另外在美国能源研究技术中心（NERSC）的超级电脑Cray XE6也是以Hopper命名，以表彰她的贡献。

1960年在UNIVAC键盘前的赫柏

3、COBOL的现状与未来

说回COBOL这个程序，我在网上问了下国内COBOL的现状，不少人给出的反馈是应用很广。特别是银行、保险、证券等行业，基本上仍然都是采用COBOL程序，我去查了查资料，来自路透社的一篇文章（*3）显示：43%的银行、80%的面对面交易、95%的ATM机业务，目前都是采用COBOL程序，目前世界上一共有2200亿行COBOL代码。

但不可否认，COBOL程序在当前确实是遇到了一些困难。有资料统计显示，在过去的五年中，COBOL的普及率呈上升趋势，但在过去的三十年中，总体下降幅度很大。从下图中可以看到，1997年COBOL程序在程序排名中排第3，到了2007年则降到了15名，2017年则为24名。（顺便说一句：Java、C、C++一直高居前几，而Python则是近年来排名上升最快的一款程序。）

至于从事COBOL的人员年龄组成，并不是像新闻中所说的那样，但确实以45-55岁的人数居多。有资料统计如下：45-55岁占41.7%，35-45岁占28%，55-60岁占14.5%，35岁以下占11.5%，60岁以上占4.3%。这个群体确实也可以成为“中老年组”了。

由于COBOL大部分运行在IBM提供的大型机上，在前几天，IBM发布了一项公告，他们与Linux基金会的Open Mainframe Project合作，为满足当前和临时需求而制定了三个新计划（*4）。

• 所有COBOL程序员论坛：新的人才门户，雇主可以在这个论坛里与经验丰富的COBOL程序员联系。（*5）

• COBOL技术论坛：新的临时资源，由经验丰富的COBOL程序员积极监控，在危机期间提供免费建议和专业知识。这个技术论坛，目前搭建在GitHub上。（*6）

• 开源COBOL培训：一种全新的开源课程，旨在向初学者教授COBOL程序，也向有经验的专业人员进行技能提升。这个课程将教编码人员如何在Microsoft流行的VSCode软件中使用COBOL，预计在下个月，IBM将在Coursera等在线学习平台上发布更加完善的COBOL课程。

4、这个事件给我们普通人的启示

之所以写这篇文章，一是好奇，二也是通过这件事想到了自身相似的问题。

首先，在企业中通常会存在很多的新老产品共存，有一些老产品不管是代码或者硬件，可能是某一个人当时写出来或做出来的，没有传承性。这种情况可能存在潜在的风险，特别是当这款产品其应用的场合比较特殊，如政府、银行等。在这个时候，我们可能需要想一些办法，比如：不要将经验放在员工的脑中，或者预判在遇到问题的时候能有一些替代方案。

其次，在企业中有一个现象。很多产品，一换主管负责人或架构师，总是不自觉地想完全推翻前任的设计，重新做或重新架构。导致相同的产品，重复投入人力和时间，产品形态差别也很大，同时给客户的使用带来了非常大的替换成本，想想俞军老师的用户价值=新体验-旧体验-替换成本，大概就能明白。这次COBOL事件，也有这个原因，新泽西州为什么不更新新的系统呢？正是因为替换COBOL的成本太高。（当然，这也从侧面说明了COBOL程序足够稳定。）

再次，我们在做产品规划或者系统设计的过程中，做正确的计划其实需要花费大量的时间和精力，包括前瞻性、应用性、可维护性、替换成本等等。所以在前期一定是多考虑，不要急着给解决方案。不一定是追求最新的技术才可行，也许适用公司的情况才是最好的。就如英语很老，规则很奇怪，但不妨碍其成为世界通用性语言一样。

最后，COBOL确实有遗留的问题，但就像说汽车已经有100年历史了，但我们并不是所有人都在驾驶特斯拉。所以遗留系统的问题不在于是用COBOL程序编写的，而是州政府在数十年前的设计尚未现代化且不认为自己的管理糟糕，且在长时间内对任何积极变化的巨大抵制才造成这样的局面。

参考资料：

1

https://zh.wikipedia.org/wiki/COBOL

2

https://zh.wikipedia.org/wiki/%E8%91%9B%E9%BA%97%E7%B5%B2%C2%B7%E9%9C%8D%E6%99%AE

3

http://fingfx.thomsonreuters.com/gfx/rngs/USA-BANKS-COBOL/010040KH18J/index.html

4

https://newsroom.ibm.com/2020-04-09-IBM-and-Open-Mainframe-Project-Mobilize-to-Connect-States-with-COBOL-Skills

5

https://community.openmainframeproject.org/c/calling-all-cobol-programmers/15

6

https://github.com/openmainframeproject