曾經(jīng)有一個編程的黃金時代，那時內存和CPU都有實實在在的限制。然而現(xiàn)在，我們生活在一個極端浪費的低效環(huán)境里。真是太可悲了。

本文最初發(fā)布于 Cliff Harris 的個人博客。

我使用的一項服務，有時會將我的一些文件上傳到某個地方（是哪家公司的服務并不重要，因為坦率地說他們都是一樣的）。舉個一個很簡單的例子：指向我硬盤上的一個文件夾，將內容復制到一臺遠程服務器上，然后他們可能會做一些與數(shù)據(jù)庫有關的操作，為那一堆文件分配一個名稱，并核實誰下載了它。

這是一家大公司，所以他們的流程很長，而且可能經(jīng)常遭到黑客攻擊，所以需要一些安全保障，也需要一些驗證，以確保我上傳的文件和他們收到的文件之間沒有被篡改過。我理解。

……但基本上，這個過程無非是列出一些文件，讀取、上傳、然后關閉連接，用一個日志文件說明是否成功，如果不成功是因為什么。這不是什么高科技。事實上，我自己也從頭寫過這樣的代碼，使用了 WinINet API 和 PHP（在一臺可以訪問MySQL數(shù)據(jù)庫的服務器上）。與企業(yè)級的東西相比，我寫的東西可能沒有那么健壯，但確實也可以支持數(shù)十萬個文件的上傳（GSB 挑戰(zhàn)數(shù)據(jù)）以及對它們的驗證、下載和記錄?；蛟S是一個程序員 2 到 3 周的工作？

電腦文件中 99.9% 的代碼都沒用

現(xiàn)如今，我使用的專用上傳工具客戶端文件總共有 230MB，這一處理過程涉及到 2700 個不同的文件。

你可能會覺得是我打字打錯了，所以我澄清下。兩千七百個文件和 237MB 的可執(zhí)行文件及輔助性的東西，只是將一些文件從客戶端復制到服務器上。臃腫、過度工程化都不足以描述這個情況了，這絕對是完全、徹底、確定無疑而又顯而易見的荒謬和瘋狂的。

問題是……我懷疑，其他任何大公司提供的此類軟件也沒什么不同。哦，還有，它給出了錯誤信息，它現(xiàn)在不能工作了。

我見過編碼人員這樣干。我知道這種情況是怎么發(fā)生的，這是因為編碼人員不僅沒有使用高效的底層代碼來實現(xiàn)他們的目標，甚至他們從來沒有見過寫得好而又高效的底層代碼。當他們都不知道有這種可能時，我們怎么能指望他們做得更好呢？

你可以用不到二十分之一的代碼編寫一個程序，將文件安全、快速地上傳到服務器。它可以是單個的文件，僅一個小小的 exe，不需要成百上千的DLL。這不僅可能，而且很容易做到，還更可靠，更有效，更容易調試，而且……讓我再嘮叨一句…..它真的可以工作。

代碼臃腫聽起來像是五十多歲、脾氣暴躁的老程序員（比如我）小題大做，因為我們年紀大，脾氣暴躁，我明白這一點。但是，我們又老又暴躁是代碼運行速度比它應該的要慢 50%時，或者是代碼大 50%時，我們才會抱怨。其實，實際情況遠比這更糟糕。我們已經(jīng)到了這樣的境地：我確信，你電腦上的文件中 99.9%的代碼絕對是沒用的，甚至從來沒有執(zhí)行過。它只是在那里，在一堆 DLL 里，全都是因為一些編碼人員想做一些微不足道的事情，比如保存一個位圖，但不知道這有多容易，所以為了實現(xiàn)它而導入了一大堆垃圾。

如我所言，我真的不應該對年輕程序員這樣做感到惱火。這就是他們學到的東西。他們不知道什么是高性能，也不知道什么是基于約束的開發(fā)。當你告訴他們，游戲 Elite 最初只有 64K，但卻提供了一個龐大的星系、3D 空間戰(zhàn)斗、職業(yè)發(fā)展系統(tǒng)、貿(mào)易以及成千上萬可供玩家探索的星球，我想他們聽到了你說的話，但并不真正理解與我們現(xiàn)在的差距。

我為何在意這個？原因有很多，其中最重要的是，如果你需要比平常多兩千倍的代碼來實現(xiàn)一件事，那么它就應該有效。更重要的是我知道，在我這臺大電腦上，99.9%的處理器時間是完全沒用的。它每秒鐘進行數(shù)十億次的操作，只是為了原地打坐。我的電腦現(xiàn)在應該處于超低功率模式，關閉所有的風扇，處于完全的安靜狀態(tài)，因為我在 WordPress 中輸入時，它只是做一些拼寫檢查。

為何我們的程序運行的很慢

如今，計算機的速度非?？欤憧梢园阉鼈兛醋魇墙^對魔法。你能想象到的一切應該都可以在刷新率的 60 分之一的時間里發(fā)生。然而，當我在我的筆記本電腦（微軟 Surface，相當新）上點擊音量圖標時，卻有一個明顯的延遲，因為機器一步步創(chuàng)建出一個新的用戶界面元素，并最終確定了要繪制的圖標，讓它們彈出，然后開始運行。這需要時間，我懷疑有半秒，以 CPU 時間計，這就像 10 億年。

如果我是對的（保守地說），我們的 PC 99%的運行時間都被浪費掉了。也就是說，計算機能源消耗的 99%被浪費掉了。這簡直是犯罪，這是要干什么？我不知道，但只要看一下電腦的任務管理器，就會發(fā)現(xiàn)一大堆臃腫的廢物，天知道它們在干什么。我現(xiàn)在正在做的就是輸入這篇博文。

Windows 有 102 個后臺進程在運行。我的 Nvidia 顯卡當前占了其中的 6 個，其中一些還有子任務。這是要干什么？我現(xiàn)在不是在運行一個游戲，我所使用的顯卡驅動程序的功能集與我二十年前的差不多，但卻需要 6 個進程。

微軟 Edge Web View 也有 6 個進程，還有微軟 Edge。我甚至沒有使用微軟 Edge。我想是因為我昨天在里面打開過一個 SVG 文件，然后就這樣了，12 段無用的代碼，浪費著內存，可能還會輪詢 CPU。

這太瘋狂了，這就是為什么我們似乎什么都沒做，卻什么都很慢。這就是為什么你每年都需要一部新手機和一臺新電視來加載那些臃腫的流媒體應用，它們也不得不運行這些糟糕的代碼。

老實說，我認為情況只會變得更糟，因為像 Facebook、Twitter、Reddit 等大而無當?shù)目萍脊臼沁@種趨勢下最糟糕的例子。很快，他們雇用的成千上萬的“程序員”在輸入時都將使用機器學習從 GitHub 上復制粘貼臃腫、有缺陷而又雜亂的代碼。只是將兩個數(shù)字簡單相加最終都將涉及 32 個 DLL、16 個 Windows 服務和 10 億行代碼。

Twitter 有兩千名開發(fā)者，Tweetdeck 偶爾會無法加載用戶欄。這種情況已經(jīng)持續(xù)四年了。我打賭沒有一名編碼人員知道為什么會發(fā)生這種情況，因為其后臺代碼非常臃腫，有很多復制粘貼來的沒用的東西。

Reddit，當從鏈接中推薦標題時，無法處理與號或分號或英鎊符號?，F(xiàn)在是 2022 年了，他們可能也有 2000 名開發(fā)人員。顯然，他們中沒有人能夠提供一個有效的文本分析器。為什么他們還都能得到報酬？

曾經(jīng)有一個編程的黃金時代，那時內存和 CPU 都有實實在在的限制。然而現(xiàn)在，我們生活在一個極端浪費的低效環(huán)境里，真是太可悲了。

查看英文原文：Code bloat has become astronomical