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

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

我使用的一項(xiàng)服務(wù)，有時(shí)會(huì)將我的一些文件上傳到某個(gè)地方（是哪家公司的服務(wù)并不重要，因?yàn)樘孤实卣f他們都是一樣的）。舉個(gè)一個(gè)很簡單的例子：指向我硬盤上的一個(gè)文件夾，將內(nèi)容復(fù)制到一臺(tái)遠(yuǎn)程服務(wù)器上，然后他們可能會(huì)做一些與數(shù)據(jù)庫有關(guān)的操作，為那一堆文件分配一個(gè)名稱，并核實(shí)誰下載了它。

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

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

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

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

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

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

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

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

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

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

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

為何我們的程序運(yùn)行的很慢

如今，計(jì)算機(jī)的速度非?？?，你可以把它們看作是絕對魔法。你能想象到的一切應(yīng)該都可以在刷新率的 60 分之一的時(shí)間里發(fā)生。然而，當(dāng)我在我的筆記本電腦（微軟 Surface，相當(dāng)新）上點(diǎn)擊音量圖標(biāo)時(shí)，卻有一個(gè)明顯的延遲，因?yàn)闄C(jī)器一步步創(chuàng)建出一個(gè)新的用戶界面元素，并最終確定了要繪制的圖標(biāo)，讓它們彈出，然后開始運(yùn)行。這需要時(shí)間，我懷疑有半秒，以 CPU 時(shí)間計(jì)，這就像 10 億年。

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

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

微軟 Edge Web View 也有 6 個(gè)進(jìn)程，還有微軟 Edge。我甚至沒有使用微軟 Edge。我想是因?yàn)槲易蛱煸诶锩娲蜷_過一個(gè) SVG 文件，然后就這樣了，12 段無用的代碼，浪費(fèi)著內(nèi)存，可能還會(huì)輪詢 CPU。

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

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

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

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

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

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