上古編程語言COBOL並不是最糟糕的遺留技術，Java 8、Python 2和jQuery纔是真要命。
當我們將時間浪費在談論大型機時，殊不知技術衰敗的威脅已經迫在眉睫。
每當我接到採訪請求，或者被邀請談論我在遺留技術現代化方面的工作時，每個人都想談論大型機和 COBOL。人們認爲，我會給其他工程師講一些有趣的戰爭故事，關於老舊系統的苦差事，這些工程師無須擔心這些事情，因爲他們的職業專注於現代技術。
當然，當我開始處理遺留系統時，我也被最古老的節目李普利的《信不信由你》 （Ripley’s Believe It or Not!）（譯註：1921 年由李普利推出）給吸引住了。挖掘和剖析老舊系統的快感，發現大多數程序員從未聽說過的、被遺忘的語言，更不用說與之交互了。我一直着迷於低級語言和系統，它們將電壓變化轉化成數學和設計中的抽象概念，這是一種什麼樣的魔法啊！但最近，我對即將到來的遺留啓示錄，以及如何減緩新技術帶來的技術債務不斷上升的水平更感興趣了。
遺留啓示錄並不是嬰兒潮一代最後一個 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 使分享變得很容易。
但如果 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 是上古語言這一事實無關緊要，而且還分散了人們對日益增長的代碼生態系統的注意力，儘管它的產品生命週期早已結束。
作者介紹：
Marianne Bellotti，熱衷於遺留系統，處理複雜系統的故障。
原文鏈接：
https://medium.com/@bellmar/old-code-gets-younger-every-year-3bd24c7f2262