BT

你的观点很重要! 快来参与InfoQ调研吧!

大型机程序员正在退休,我们是否会担心?

| 作者 Don Denoncourt 关注 0 他的粉丝 ,译者 盖磊 关注 1 他的粉丝 发布于 2017年11月14日. 估计阅读时间: 19 分钟 | ArchSummit社交架构图谱:Facebook、Snapchat、Tumblr等背后的核心技术

本文要点

  • 大型机程序开发人员不仅正在退休,而且正在过时。年轻一代的开发人员对大型机职业生涯兴趣索然。
  • 大型机程序开发人员曾被比成是公共汽车驾驶员,他们唯一的工作就是让大量的数据持续移动。
  • 大型机并非老化了。如果与Microsoft和Linux在性能、扩展性、安全和可靠性上做对比,大型机完胜。
  • 代码重构为可复用模块的过程中,应使用测试,并采纳敏捷实践。大型机应用的现代化并不能体现为月度财报中的投资回报率。

我们经常使用Uber、浏览Pinterest、发送推文并更新Facebook。我们每天都会听说一些人快速成为百万富翁,看到亿万富翁的数量在不断增长,他们不断地在我们现在的高科技世界中推出一些最新玩意。但是我们忽视了一点,所有业务的近乎70%是在大型机上处理的。那些年轻网红匆忙拼凑起来的玩意,充斥了我们所见所闻的世界。但事实上,我们所坐的椅子、所支付的账单、所使用的健康医疗,都是由大型机所管理的数据提供的。的确,80%以上的制造业、银行业和健康医疗行业是运行在大型机上的。

我们能听到大量关于新市场货币化的宣传,但却没有认识到大型机代码的重要性。当然,这里存在一些问题……很多大型机开发人员是接近或已经过了退休年龄的爷爷级人物。现实中更严酷的一面是,他们不仅正在退休,而且正在过时。(让我们为去年去世的Jim Stanicki和John Stalher做一个短祈祷,他们是两位典型的大型机开发人员,也是我的朋友。)

代码重写

我们是否应该重写旧的大型机应用?这不容易实现。当然我知道,大家已对代码重写耳熟能详了。不少并非大型机应用的Visual Basic、dBase III和PHP程序会每隔五年就重写一次,原因在于它们的代码写得并不是很好。而与此同时,我们看到大型机应用已经良好运行数十年了。重写大型机应用的ROI(投资回报,Return On Investment)并非在于此。举个例子,我在上世纪八十年代中期为Hanover Brands有限公司编写了的流量系统目前依然在使用。

但是现在我们面对着退休和过时的问题。那么我们为什么不能硬着头皮去做重写?

重写从来就不是一件容易的事情。对于大型应用,重写常常会失败。就在数个月前,我为Ruby and Rails重写了一个小小的简单PHP应用程序。尽管我精通Ruby并熟悉PHP,并且这一程序只有一千行多点,但我还是丢失了一些内容。大型机的COBOL和RPG应用则略为复杂。使用RPG编写的程序,一万多行是很常见的;而如果使用COBOL编写,动辄具有两万多行。如果代码需要在上百个程序中复制,那么一个应用就会有上百万行的代码。更糟糕的是,其中不少程序是在模块化编程技术出现之前编写的。因此,在这样庞大代码中的所有变量是全局的。记得在数十年前,我曾在文章和研讨会中十分关注这一问题,我们像第欧根尼(译者注:Diogenes,古希腊哲学家,犬儒学派的代表人物。他所做的一件事情是,每天白天打着灯笼在街上“寻找诚实的人”)那样在大型机代码中寻找局部变量。第欧根尼从未发现诚实的人,在70年代前后的代码中寻找变量中也存在着同样的问题。

RPG程序本身就是非常难以阅读和理解的。多年来,RPG语言一直只能用六个字符表示变量名。事实上事情更糟,RPG语言存在一些软件缺陷。如果我们在两个不同的表中使用了同一列名,那么它们将共享同一内存空间。因此为了识别变量所关联的系统表,RPG程序人员需要使用二到四个如此珍贵的六字符列名。该软件缺陷在二十年前才被修复,现在它的变量和数据库列名长度支持32个字符。但是在RPG程序中,六字符变量名依然占据主流。

在1992年前后,此时我是Circuit City编程团队中的一员。当时我就COBOL模块化技术为团队做了一次演讲。演讲后,团队中一位最优秀的COBOL编程人员指出,她并未看到COBOL模块化的好处。

大家知道,在讨论一个函数是否应该超过6或9行的问题上,我可以与其他Ruby开发者争得头破血流。在Ruby开发中,如果你肆意使用全局变量,完全可能会被解雇。所以当我回想起这些一万到两万行的程序时,不禁哑然失笑。维护使用Cobol和RPGb编写的庞大代码,这往往比巫术更诡异。如果要尝试做一些直觉上可以工作的更改,我们要点上香并撒上圣水,向各方神灵祈祷这一更改会奏效。

Cobol和RPG的主流开发实践中充斥着过时的语法。我们谈论的是丑陋的代码。在一个程序中经常会有数千行代码被注释掉,还有许多部分是完全没有使用的。查看这样的代码就像走进一个有囤积癖好的人的房屋,其中充斥着无用的垃圾。更过分的比喻是,垃圾堆越多,就越容易腐烂,并且会发出恶臭,正如我们所讨论的代码味道。事情是,我们每天都会用到的流程和数据都会流经这个腐朽的旧代码,而它的维护人员正在退休和过时。

敏捷

老实说...我从这一职业生涯中跳出来的原因在于大型机开发的速度,或者说缺乏速度。RPG和Cobol的开发实践和工具集已经衰落。诸如测试驱动开发、源代码控制、现代编辑、代码重构、敏捷等理念,多年来我一直致力于将它们转化为文字,并付诸文章和研讨会中。但是在RPG和Cobol开发项目中,我不仅需要忽视其中大部分理念,而且几乎找不到可以使用这些理念的项目。

对于上一段话,我重点说一下其中的敏捷性问题。大型机应用程序开发实践缺乏敏捷性,因此很难以适应市场需求。通常,考虑到此类旧应用程序的失败,以及它们的支持人员即将退休,C级别高管(译者注:指具有CTO、CEO、CFO等头衔的企业高管)会建议采购昂贵的ERP系统,或是完全重写。我们都听说过这样项目的相关恐怖经历。

现代机器

我们应了解,大型机并非过时的。它们并非System 360和AS/400这样的昨日黄花,而是IBM z/OS和IBM i这样的64位操作系统,具备Linux和Windows所无法企及的可靠性和可扩展性。它们对于复杂数据中心而言,自建的整体成本也较低。我们可以横向扩展大型机,而非纵向扩展。 在大型机上也可以运行最新的软件。例如,我们可以在一台主机上运行数千个Docker镜像。运行在i系列机器上的DB2数据库,可以说是这个星球上最好的数据库。至于热门技术,几年前,我在一个团队中实现了将Ruby and Rails移植到本地IBM i操作系统上。银行应用程序是在大型机上运行的,这主要出于安全上的考虑。正是银行家资助了Rails迁移到IBM i平台。大型机具有巨大的优势,涉及从巨大的横向增长到最终的安全性、近乎100%的可靠性。当然,尽管事实上IBM销售大型机的数量在减少,但现有机器提供了很好的升级和扩展,因为它们具有天文学量级的水平可扩展性。

老化的并非机器,而是大型机的应用程序和程序开发人员。

事情是否已经搞砸了?

我们曾担心千年虫会让大型机崩溃,事实上它并没有。一起都很好。这是因为管理层最终开始认真对待从两位数转到四位数的问题。如果管理层能认真对待关键技能的损失这一问题,一切都会好起来的。

下面在详解介绍具体细节前,让我概括一下我给出的解决大型机编程人员退休和过期问题的方案:

  • 数据库的现代化;
  • 应用代码的重构;
  • 培训现有大型机开发人员的敏捷,并薪火相传;
  • 挑选优秀者成为大型机开发人员;
  • 将已有代码转换为API。

数据库的现代化

第一步是数据库的现代化。隐藏在这些二十至四十年前的应用程序之后的,是保存在世界上最好的数据库和操作系统中的大量数据。许多大型机数据库的创建,要先于今天众所周知的数据库规范化和优化技术的创立。就在十年前,我还是要把Web前端置于明显之处,放在一张牌桌上。一些工具和可用技术可以让我们继续运行遗留应用,无需修改旧的数据库模式结构。根据我的经验,重构数据库并非难事。

应用代码的重构

我早些时候对大型机代码现状表示出了强烈的不满。现在我知道,大型机代码可以被重构到更为敏捷的程度。我并不是要探讨重构本身。重构是一种在不改变代码行为的情况下重新构造代码的过程,因此C级别高管不应该担心大规模重写可能会导致停机的问题。

重构的第一步是将代码置于源代码控制下。我强烈推荐使用git。或许你的大型机代码已经使用源代码管理包管理,但是我对大型机源代码管理包的经验是,它们助长缓慢的开发,并阻碍常见的重构策略。只要代码置于git管理之下,那么我们可以删除掉注释的代码,因为保留旧版本的代码是源代码管理的工作。

重构的第二步是更新开发环境。虽然功能强大的IDE出现了二十多年,许多大型机开发人员仍然使用字符编辑器。这些现代IDE是与重构工具一起绑定使用的。

第三步是建立单元测试策略。 单元测试通常会对程序行为做出非常具体和详细的测试。这是我们没有时间去做的事情。我建议遵循由Llewellyn Falco (http://llewellynfalco.blogspot.com/)提出的“批准测试”(Approvals Testing)策略。审批测试的基本理念是分别做执行例程之前和之后的状态快照。该快照可以是任何内容,从数据库的查询结果到PDF、CSV格式的文档。发挥你的创意吧!在存储了快照后,我们就可以修改例程,并使用之前和之后的映像去验证重构并没有改变行为。虽然在调用大型机例程时,最终可能会使用使用到Java、Ruby或Python的测试基础结构,但此类操作并不复杂。

如果构建了单元测试策略,重构应该最先实现变量名称可读和易于理解。然后再开始进入模块化的过程中,尽量减少使用全局变量。在大型机代码中,重复代码泛滥,所以我们需要借助于工具去查找重复代码,然后对它们创建一些通用模块。

授权现有开发人员

重构策略的关键是在于最好的大型机开发人员。忠言逆耳,但是大型机开发人员已被他们的雇主看成是巴士司机的角色。管理层认为开发人员的工作就是在各点间移动数据。一旦这一过程发生中断,开发人员就需要去修理引擎,直到他们能够回到大巴上并继续移动数据。从我个人的经验看,他们往往不受重视并且报酬过低。其中不少大型机开发人员没有学位,并且相对于C级别高管和常青藤联盟MBA学员,他们似乎并不具备考虑下个季度投资回报率的能力。

我们应授权这些大型机开发人员。就敏捷开发实践对他们进行培训,并且他们自己也要成为培训师。他们需要在重构和其后的模块化API创建上得到帮助。我们还应考虑到退休和过时的问题,因此管理新开发人员的培训应是授权大型机开发人员的一部分。

如果在现有的主机开发人员中,没有人能站出来成为项目主管,那么我们就应该从外面招聘一名。问题在于,虽然有许多人具备推进此工作的能力,但他们可能已经转向了管理或培训,或是像我一样转向了其它的编程语言和平台。与这些人相关的一个问题是,他们在几十年前就厌倦了走马灯式(Revolving door)的C级别高管,这些高管拒绝了大型机开发现代化的建议。许多这些前主机开发人员可能只是会建议去购买ERP,给Oracle打电话,或者完全重写,尽管就他们的经验来看这可能会是失败。所以准备好轮流与这些人打交道。

那么在哪里可以找到这些曾经的大型机开发人员?我们可以在LinkedIn上搜索具有良好沟通技能、新技术和敏捷上的经验并试图隐藏大型机经历的人,也可以参加Java、Ruby、JavaScript等会议并与50岁以上的开发人员交谈。从他们的年龄看,他们可能曾经是大型机开发人员,并熟悉新技术,最重要的是敏捷开发。

如果读者知道自己在找什么样的人,那么我们可能不需要介绍得过多。本段内容可能会被裁掉,因为本文编辑曾是一名大型机开发人员,也是一位敏捷教练。他可能会裁掉本段内容,因为他几年前就辞去了“大巴司机”的工作,并找到了一个类似于他的人去管理大型机现代化项目。[编者按:不,我并未裁掉本段,因为我同意作者的说法。]

挑选优秀者成为大型机开发人员

大学并不会教Cobol和RPG。在一些关注“技能消亡”问题的博客帖子和文章中,建议大学应增加添加大型机的课程,吸引千禧一代从事大型机职业。

我不认为吸引千禧一代是一种解决方案。我不会建议任何年轻人在大型机上发展自己的职业生涯。这一行业就业机会少得多,发展速度也缓慢,职业生涯不会太顺利。我的建议是:一、对现有的非IT人员再培训;二、强制三四十岁的人进入大型机行业。这两个建议听起来都很疯狂,但是对于愿意在大型机上开始其职业生涯的年轻IT毕业生,我对他们的能力心存质疑。

比当今风行的的多态、多平台的程序开发人员,成为一名大型机开发人员所需的技术知识更专一。公司需要的不是具有NodeJS和函数式编程技能的人,而是具有商业头脑的人,他们渴望学习,而且非常简单和聪明。有很多非IT专业的聪明人,他们正经历职业中期焦虑,在经过一年的职业训练后会有机会薪酬翻倍。一个值得挖掘的领域是退休人员。

将代码转换为API

将重构的代码转换为API,是大型机现代化过程的最后一步。这些应用将成为可重用的软件组件。通常,大型机代码的参数列表非常复杂,创建API似乎是不可能的事情。鉴于此,我们要创建一个或多个包装程序,这可以使用Cobol或RPG编写,也可以选择新语言编写。我喜欢使用的技术是创建包装传统模块的SQL存储过程。使用SQL存储过程时,任何具有SQL接口(例如JDBC,ODBC驱动程序或其它)的人都可以使用这些例程。

使用通过API(例如SOAP,REST或其它)提供的遗留代码,并使用面向所有的单元测试,可以做到完全敏捷的开发。可以选择任何语言编写新的代码,当然这些工作可以雇用千禧一代完成。

一些更为敏感和复杂的程序,它们可能在客户流失报告中位列前茅,现在已经可以转换为新语言编写。

大型机的敏捷

尽管大型机应用程序在过去的半个世纪内都是非常的可靠,但它们几乎没有做任何自动化测试。而大型机从业者或者是不了解重构策略,或者在启动重构问题上没有得到C级别高管的支持。总而言之,代码已经不适应不断变化的业务需求。现有的大型机开发人员正在以惊人的速度退休,劳动力也没有得到补充。

摆脱大型机远非最理想的解决方案。重写或转换为ERP的实现代价昂贵,并且充满风险。但是大型机本身没有老化。事实上,它们在性能、弹性、安全性和可靠性等方面完全超越Microsoft和Linux。并非是机器在老化,而是应用程序和程序员正在老化。

我们要做的是实现数据库的现代化、代码的重构、成为敏捷并加强对编程人员的内部培训。最后在大型机展现出优势之处,开始将新模块化的代码转换成新语言编写。

问题在于,上述解决方案都取决于C级别高管的采纳。高管在采纳之前,需要审视季度业绩,并考虑未来两到五年内,如果失去这些被低估的大型机开发人员会有什么样的后果。

本文作者

Don Denoncourt 是simplethread.com的一名开发人员。在Windows和Linux时代开始前,他就一直在编码,更不用说互联网时代了。在九十年代初,Don从RPG和Cobol开发转向C和C++开发。在1996年,他先于Java发布使用了Java。在以自己的方式使用Java框架扩展(包括Struts,Spring和EJB)编写代码后,他开始使用Ruby and Rails的Convention-over-Configuration框架。在2011年最终定格在Rails开发之前,Don做了Groovy和Grails开发。Don喜欢写作,并且出版了多本书和数百篇技术文章。自上个世纪以来,Don一直在国内工作。在工作闲暇之余,Don喜欢和三个孙子在一起。为了让自己的思想保持年轻,Don用意大利语阅读和聆听小说。并且为了使自己的身体保持年轻,他也是一名狂热的越野爱好者和街头骑士。

查看英文原文: Retiring Mainframe Programmers: Should I Care?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

佩服 by zhou Glamey

Don Denoncourt 这位老人家真心不一般呀,收下我大写的佩服。

大型机开发人员的老化可能源于失去对技术进步追随的热情 by lyu alan

老化的开发人员大多工作在大型的传统企业机构,他们的老化从一个侧面反映了这些机构管理的老化,很少见到这些机构的那些带C级别的高级技术管理人员是热衷追随技术进步的,更多的时候他们大谈成本管理和站在业务机构部门一面谈及商业价值的提升, 老实说,如果业务人员都需要技术人员谈业务价值,那我要你们干什么?
好吧,这么浅薄的看法来自一位老程序猿的狭隘观点,还是说说如何处理那些动辄几万行的cobol程序吧,你指望现有的开发人员用cobol来做重构,这个太具有挑战性了, 为了开发人员的职业生涯(如果5年之内不能退休)考虑, 毋宁重写,我完全同意Don所说API的方向,但最好使用OOP来做,用java的好处之一是可以跟不少同龄人(略年轻点)畅谈编程体验和交流心情。一点一点的重写部分功能代码,借着做日常业务需求的项目机会尝试逐步提供一个个API,要知道,如果你在小幅增加成本的同时提供新的东西给C级别的官员们,并讲一个好的价值故事,他们是非常乐于支持的。还有一点,在国内目前充斥着开发人员30岁后就要转型管理的论调中,大型机开发人员在35岁之后转型编程语言以及学习新技术(如云计算)可谓是一股清新之风。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT