程式員退休后，各種編程語言的遺留系統怎么辦？

上古編程語言 COBOL 并不是最糟糕的遺留技術，Java 8、Python 2 和 jQuery 才是真要命，

當我們將時間浪費在談論大型機時，殊不知技術衰敗的威脅已經迫在眉睫，

每當我接到采訪請求，或者被邀請談論我在遺留技術現代化方面的作業時，每個人都想談論大型機和 COBOL，人們認為，我會給其他工程師講一些有趣的戰爭故事，關于老舊系統的苦差事，這些工程師無須擔心這些事情，因為他們的職業專注于現代技術，

當然，當我開始處理遺留系統時，我也被最古老的節目李普利的《信不信由你》 （Ripley's Believe It or Not!）（譯注：1921 年由李普利推出）給吸引住了，挖掘和剖析老舊系統的快感，發現大多數程式員從未聽說過的、被遺忘的語言，更不用說與之互動了，

我一直著迷于低級語言和系統，它們將電壓變化轉化成數學和設計中的抽象概念，這是一種什么樣的魔法啊！但最近，我對即將到來的遺留啟示錄，以及如何級訓新技術帶來的技術債務不斷上升的水平更感興趣了，

PS：文章末尾有驚喜哦！

遺留啟示錄并不是嬰兒潮一代最后一個 COBOL 程式員的離世，說實話，這場危機來得快，走得也快，當人們談論老舊系統的威脅時，他們喜歡搬出有關 COBOL 程式員年齡的統計資料來說事，

例如，在 2006 年，COBOL 程式員平均年齡為 55 歲，這聽起來很糟糕啊！許多關鍵員工都快退休了！他們要是離開了以后，誰來照看他們留下的系統呢？

平均值可能會誤導公眾，在同一調查中，有 52% 的程式員年齡在 45~55 歲之間，34% 在 35~45 歲之間，但更重要的是，8 年以后，當那些 55 歲的程式員都應該退休的時候，Micro Focus 對 COBOL 程式員和高管的調查將 COBOL 程式員的平均年齡再次定為 55 歲，他們在 2019 年的調查中得出的平均值就是 50 歲，

實際上，幾十年來，COBOL 程式員的平均年齡就一直保持穩定，當我父親研究千年蟲問題時，當時他都已經 40 多歲了……快 50 出頭，他的同事年齡與他相仿，每次我看到人們在 COBOL 社區的年齡上大做文章的時候，我就會想起美國雙簧管演奏家 Blair Tindell 寫的關于古典音樂界的文章：

對聽眾老齡化的恐慌大可不必，因為我們忽略了一個事實：其實聽眾平均年齡在 40 歲左右已徘徊了一段時間，人們等到中年才開始欣賞交響樂，是合乎邏輯的，隨著孩子長大，學費付完，人們才有了更多的閑暇時間，音樂會很符合成熟后的嬰兒潮一代豐富的生活方式、品味和收入，

關于 COBOL 也可以有類似的說法，與 60 年代、70 年代和 80 年代的年輕程式員不同，今天的年輕程式員上大學的時候沒有接觸過大型機，

如果大學里還有大型機的話，那就是行政部門的主力機器，對于學生專案來說太重要了，年輕程式員也沒有學習 COBOL 的選擇，就算他們做了數百個（或者有些人說是數千個）COBOL 作業，也不是入門級的，

COBOL 程式員的平均年齡之所以穩定，很可能是因為 COBOL 程式員在職業生涯后期轉向 COBOL 之前，已經在其他語言方面積累了豐富的經驗和專業知識，

人們總是擔心那些上了歲數的 COBOL 程式員，因為他們認為，當最后一批 COBOL 程式員離世后，他們開發的程式將無人能夠維護，人們有這種擔心是情有可原的，但是，大多人會驚訝地發現，無法維護的遺留代碼帶來的威脅比他們想象的要近得多，

? 64% 的 Java 應用程式停留在 Java 8 上

如果你還記得的話，Java 的最新版本是 14，Java 8 應該在 2019 年就停止支持了，

Java 9 引入了結構上的一些變化，使 Java 更加模塊化，因此 Java 9 對嵌入式系統來說更加可行，從 Java 8 轉到 Java 9 并不是升級，而是全面遷移，

其中，Java 9 使 JDK 內部的 API 無法訪問，它剔除了一些工具和方法，而且向模塊化結構的轉變需要更改依賴關系，換句話說，從 Java 8 遷移到 Java 9 有可能意味著很多代碼必須重寫，

因此，Snyk 在 2020 年進行的關于產品應用程式的調查中，發現超過一半應用仍然運行在 Java 8 之上，

? Python 2

和 Java 8 一樣，Python 2 也一直揮之不去，因為遷移到 Python 3 既要重寫自己的代碼，又要從所有依賴關系中移除 Python 2，

雖然有像 Benjamin Peterson 的 Six 這樣的工具可以使任務變得更愉快，但依賴關系可并不僅僅是包和庫，代碼運行的平臺也是一個依賴關系，而且這些平臺的回應速度很慢，

盡管 Python 是一個極其流行的腳本工具，但 AWS Lambda 直到 2017 年才支持 Python 3.6，而這一支持也是 Python 3.6 發布一年之后的事，同年 Salt 才提供 Python 3 的支持，一年后，Ansible 也支持了 Python 3，但此時已經是 Python 3 最初發布的十年之后了，

很難說世界上還剩下多少人在使用 Python 2，據 JetBrains 估計，這個數字只有 10%，而且這個調查是來自 150 個不同國家的 2.4 萬名受訪者，因此這一數字可能是準確的，

Python 2 的問題不在于還在使用的應用有多少，而在于它仍用于哪些地方，根據 JetBrains 的說法，Python 2 與 Python 3 仍存在競爭關系的領域是 DevOps/ 自動化、測驗和網路編程，

事實證明，要讓不同風格的 Linux 完全支持 Python 3，是一個巨大的挑戰，這場戰爭還沒有結束，每個熱愛 Mac 的 Python 愛好者都知道，由于 MacOS 內部工具的緣故，Apple 計算機在出廠時仍然以 Python 2.7 為默認的 Python 版本，

? 人人皆煩 jQuery，但它無處不在

依賴地獄的另一層是 jQuery，只是從 jQuery 遷移出來并不難，但很多其他東西都依賴于 jQuery，依賴關系會讓遷移變得很困難，

2019 年，Twitter Bootstrap 最終將 jQuery 從依賴項中移出，只是因為他們直接將 jQuery 的原始碼復制粘貼到 Bootstrap 中，即便如此，整個專案從開始到結束，也耗費了兩年多的時間，

jQuery 是自身成功的犧牲品，它簡單的語法如此流行，以至于其他框架，甚至連原生 JS 都開始采用它，最重要的是，許多 jQuery 提供交叉兼容的遺留技術最終都退役了（看看你的 IE 瀏覽器），

我個人認為，圍繞 jQuery 的擔憂有些夸張，但我不是 JavaScript 專家，這場反 jQuery 運動似乎是由于框架和當前流行的 MVC JavaScript 框架 React 之間的沖突而拉開序幕的，

但是，就像所有的技術圣戰一樣，反對選擇一個選項而不是另一個選項的合理論據，重復的次數越多，就越模糊不清，在某些方面，我認為 jQuery 的故事與 COBOL 的故事最為相似，因為有關它的頭條新聞無處不在，暗示著因為其他技術也可以做同樣的事情，所以其他（更新的）技術必定更好，

? 深度，而非年齡

遺留系統難以維護的原因有很多，負責維護的程式員的年齡并不是原因之一，誠然，機構記憶的丟失很重要，當最了解系統的程式員離開時，機構記憶也會隨之而去，但這并不是老舊技術獨有的問題，組織也有因員工被挖墻腳而失去機構記憶的情況，就像他們因員工退休而失去機構記憶的情況一樣（可能還要多），

譯注：機構記憶（institutional memory），看字面似乎不太易懂，它的意思是機構的集體性經驗結晶，是指整個機構內所有員工的總體經驗或記憶結晶，輕易解雇老員工就會喪失“機構記憶”，因此，機構記憶也可以認為是機構的經驗傳承制度化記憶，

確實，精通 COBOL 的工程師人才庫是有限的，但通過建立培養 COBOL 人才的管道，解決這個問題花不了多少錢，也不難，IBM 在這一領域一直非常活躍，他們有“大型機大師”（Master the Mainframe）計劃，COBOL 程式員是一種正在枯竭的有限資源？沒有的事，

我不得不說，以我的經驗來看，每當一個 COBOL 系統出現故障時，幾乎從來都不是 COBOL 本身引起的，我見過硬體故障、支持或以其他方式與 COBOL 集成的非 COBOL 系統引起的問題，我還見過因為 COBOL 代碼的檔案不完善而導致新特性的添加延遲，工程師需要找出更改的方法……

但我還沒有見過很多系統使用 COBOL 這一事實本身就是問題的情況，這并不是說，放棄 COBOL 沒有很好的理由，理由肯定有，我只是不傾向于同意公民社會不能在接下來的 60 年里繼續運行數百萬行 COBOL 代碼，要繼續運行？當然可以，

另一方面，Java 8 和 Python 2 才是更嚴重的威脅，當系統無法擺脫產品壽命結束（End-of-life，EOL）的技術時，它們就會錯過安全更新、性能增強和新特性，系統停留在自己的技術債務上的時間越長，建立在它們之上的東西就越多，遺留的東西就越更加根深蒂固，

當我們表現得好像關于遺留代碼日益增長的威脅的對話以 COBOL 開始和結束時，對于程式員是一種傷害，整整一代軟體工程師都在把他們的應用程式除了最獨特的方面之外所有的方面，都外包給了大量的庫、插件和模塊，而這些庫、插件和模塊他們根本無力監控，更不用說更新了，這才讓問題變得更糟糕，

遺留啟示錄中真正的騎士是依賴樹的深度，現代軟體開發將抽象堆疊在抽象之上，如果說 2016 年的“left-pad”事件沒有證明什么的話，那么它至少證明了這一點：即使是有經驗的工程師也會在他們的應用程式中使用依賴關系，如果有基礎設施可以使它們的安裝變得容易的話，

現代開發人員環境就是一個名副其實的、廉價而方便的依賴關系的“糖果店”，

? 框架的興起

如果維基百科（Wikipedia）可以被認為是一個權威的來源，那么圍繞開發全新編程語言的活動在 20 世紀 90 年代達到了頂峰，當時很多人都可以使用計算機，但抽象程度仍然相對較低，

直到互聯網的出現，改變了這一局面，不僅使更復雜的分布式系統成為現實，而且還擴大了安全問題的爆炸半徑，人們對更好的性能和更好的安全性的需求，使得在現代機器上使用新語言的 MVP 相當復雜，

聰明的計算機科學家再也不能建立概念驗證不成熟的語言，并期望將它們應用于現實世界的問題，以推動它們的進化，編程語言需要為程式員處理大量復雜的任務，

因此，盡管專業程式員的數量自 20 世紀 90 年代的輝煌時期以來急劇增長，但這些軟體專家已經從開發新語言轉向開發新框架，

而從本質上講，框架不過是一個給定了通用介面的依賴關系的集合，誠然，框架能夠使軟體開發速度更快，但它們也剝奪了開發人員維護代碼的能力，工具的進步降低了軟體開發的速度，不可避免地加深了一般軟體專案的依賴樹，

以 Node.js 為例，Node 是一個有趣的框架，它使得在服務器端運行 JavaScript 成為可能，但它也引入了一個名為 NPM 的精巧的小包管理器（作為一個依賴項），

以前也有過包管理器，NPM 未必是最好的，但它從之前的包管理器中吸取了一些教訓，提供了更好的用戶體驗，默認情況下，它是在本地而不是全域安裝的，命令列從一開始就被設計成與包倉庫集成，所以創建和發布新包是非常容易的，

因此，NPM 上依賴樹的平均深度是 4.39 個包，而同類包管理器（這里以 PyPi 為例）的平均深度是 1.7 個，Python 開發者并不是天生就比 JavaScript 開發者更負責任，

JavaScript 缺乏一個好的核心庫，而且它曾經是一個玩具語言，設計和實作都是在一個星期內完成的，這使得開發框架來平滑它的粗糙邊緣的時機已經成熟，有很多 NPM 包做一些小的、“愚蠢的”事情，而這些事情在其他語言中是以內置函式的形式出現的，NPM 使分享變得很容易，

包依賴關系對比：NPM 與 PyPi，真是可怕的對比，

但如果 ECMA 決定像 Java 9 和 Python 3 試圖解決其語言的結構性問題那樣，修復 JavaScript 的一些缺點，會發生什么呢？NPM 上大約有 60% 的軟體包已經有一年或更長時間沒有更新了，盡管缺乏維護，但這些包仍然被下載了數十億次，

ECMA 在他們的“One JavaScript”政策中承認了這一事實：

但我們如何才能擺脫版本控制呢？通過始終保持向后兼容，這意味著我們必須放棄一些清理 JavaScript 的雄心壯志，我們不能引入破壞性的變化，向后兼容意味著不移除特性，也不改變特性，這一原則的口號是“不要破壞 Web”，

我們可以針對永遠向后兼容的好處爭論一整天，但問題是，隨著 JavaScript 框架的普及，JavaScript 一直以來固有的、巨大的依賴路徑已經變得無限糟糕，因此，同樣的工具在解決像 JavaScript 這樣的語言的大量結構性問題的同時，也使得這些問題無法在新版本的 JavaScript 中得到解決，

當我們談到長期維護健康和安全的技術系統時，這比 COBOL 程式員時代的威脅要大得多，然而，當我們談論遺留技術時，并沒有談論這些問題，

? 總結：戰略高于速度

依賴關系是一種必要的“邪惡”，但使用依賴關系，并不一定要讓專案墮入遺留的地獄，我們需要開始將長期維護目標納入關于技術選擇的談話中，JavaScript 框架創建了深度依賴樹，是的，但是即使 NPM 是為了滿足后端語言的需要而開發的，其上的 80% 的活動都與前端有關，

設計界普遍認為，網站大概每兩三年就會重新設計一次，所以，從遺留技術現代化的角度來看，擁有大型依賴關系圖的 React 前端與擁有同樣大小的依賴關系圖的 Node 應用程式相比，不那么需要擔心，

換句話說，我們需要開始批判性地思考我們期望某項技術能持續多久，并捫心自問，我們在構建它時所做的選擇，是否會使它在以后更難被移除，我們再也不能坐等更好的結果出現，我們必須假設的是，更好的結果終將出現，

最后，我們需要重新聚焦話題，不要再因為技術老舊、是由老人編程就將技術妖魔化，

世界上有很大一部分的 COBOL 應用程式，在 COBOL 上表現很好，確實存在的問題也可以在 2002 年構建的 Webapp 中找到，COBOL 是上古語言這一事實無關緊要，而且還分散了人們對日益增長的代碼生態系統的注意力，盡管它的產品生命周期早已結束，

————————————

看到這里你是不是對“C語言”又有了一點新的認知呢~

如果你想當學C語言，小編推薦一個程式員編程學習基地【點擊進入】！

涉及到：C語言、C++、windows編程、網路編程、QT界面開發、Linux編程、游戲編程、黑客等等......

編程入門資料：

?推薦學習書籍：

一個活躍、高逼格、高層次的編程學習殿堂；編程入門只是順帶，思維的提高才有價值！

最后希望你也能成為自己心目中的完美物件~能成為自己心目中的完美物件~

標籤：其他

上一篇：盤點：2020年5種流行的 AI 編程語言，就業高薪不是夢！

下一篇：丑數