作為一名從事遊戲設計和編程業務的個體戶，克里夫斯基（Cliffski）在本月早些時候的一篇博客文章中吐槽道—— 這年頭的“代碼膨脹”，已經到了令人髮指的地步。以某項服務為例，Cliffski 有時必須在某處上傳基本沒差的文件—— 基本上指向了本地驅動器上的一個文件夾，並將內容複製到遠程服務器上。

（來自：Cliffski’s Blog）

服務商可能會在遠程服務器上做一些與數據庫相關的事務，來為這堆文件分配一個名稱、並驗證都有誰去下載了。

作為一家大企業，服務商有著相當龐雜繁複的流程、且難免被黑客入侵給盯上，所以必須落實較高的安全性策略，並在Cliffski 從本地上傳、到服務器遠程接收的過程中驗證文件未被篡改。

基本上，我們是在談論枚舉一些文件，讀取後上傳、接著用一個日誌文件來結束連接，並給出它是否有效（或出了什麼岔子）的結論。

儘管沒有火箭科學那麼複雜，但事實上我自己從頭開始編寫了這些代碼，並在與MySQL 數據庫通信的服務器上使用了wininet API 和php 。

與企業級事務相比，Cliffski 的產品可能沒有那麼健壯，但它確實支持著數十萬上傳的文件，以及相關驗證、下載和日誌記錄，一位程序員可能需要維持工作2-3 週。

而他當天必須使用特殊的上傳工具，去提交大約230MB 的客戶端文件—— 裡面設計2700 個不同的文件來管理該流程。

你可能會認為這是一個讓人尷尬的錯字，但Cliffski 本人很是清楚，他只是將這些雞零狗碎的內容從本地複製到了遠程服務器而已。

問題在於，Cliffski 懷疑這個上載器與這些天來自任何其它大公司的同類產品基本沒差。順道一提，它已經報錯提示不起效了。

我見過不少程序員在幹這種爛活，我知曉這種情況是怎麼發生的。

因為我們的工作不涉及通過底層的高效代碼來完成工作，且許多人甚至從未寫過所謂的好代碼。

當他們明白自己根本沒這個能力的時候，我們又該如何期待他們可以做到更好呢？

你可以編寫一個精湛的程序，它的代碼量小到只有1/20，足以將文件安全、快速地上傳到服務器。它可以是一個單獨的.exe 可執行文件，無需成百上千的動態鏈接庫（DLL）。

不僅可行，而且簡單、可靠、高效、易於調試。只需稍微努力那麼一下，它就會起到切實的作用。然而在代碼日漸臃腫的當下，許多程序員的心態也變得老態龍鍾、暴躁且易怒。

在这种情况下，代码可能因为膨胀了 50% 而运行缓慢。我甚至可以断定，你 PC 文件中有 99.9% 的代码没个屁用。

它們甚至永遠都不會被執行，但就杵在那裡。在一套65 個DLL 中，很多都涉及一些瑣碎的事情，比如原本可以簡單集成的一個位圖保存功能。

雖然要克制住不對年輕程序員的這種行為大發雷霆，但他們本該學會這些。遺憾的是，他們沒有意識到何謂高性能或基於約束的開發。

舉個例子，當年一個僅6 4K b 的《Elite》遊戲，就包含了龐大的星系、3D 太空戰鬥、職業發展系統、交易、以及數千顆可供探索的行星。如此巨大的落差，著實讓我們有些繃不住。

誠然，現如今的計算機速度已經快到可以忽略。但當我點擊微軟新款Surface筆記本電腦上的音量圖標，然後等著標稱60Hz 刷新率的屏幕上慢慢彈出UI 元素時，卡頓的感覺依然很不好受。

在你在懷疑自己到底有沒有點下去的這半秒鐘時間裡，頻率動輒數GHz 的處理器世界裡，早已過去了數十億年。我們浪費了個人計算機99% 的算力和能耗，這甚至可以說是一種犯罪。

想像一下，在你急著想要在資源管理器中快速檢索目標內容的時候，任務管理器卻在那搞一堆廢話，天知道Windows裡那102 個後台進程在幹什麼！

在裝了英偉達顯卡驅動的設備上，Cliffski 看到有6 個進程，且其中甚至附帶了一些子任務。

讓人不解的是，我們此時明明還沒有運行任何遊戲，且顯卡的功能集和20 年前相比都大致相同。

Microsoft Edge Web View 竟然也在那杵著—— 即便Cliffski 根本就不用Microsoft Edge 瀏覽器。

我猜測昨天可能在其中打開了一個SVG 文件，結果另外12 段無用的代碼浪費了不少內存和CPU 輪詢資源。

或許正因如此，我們才在幾乎沒有乾任何事情的情況下，設備的一切響應都還是那麼遲鈍。

你甚至需要每年都換一部新手機、新電視，以運行那些臃腫不堪的流媒體App —— 只因為它們依賴運行的代碼是如此糟糕！

更讓人感到絕望的是，以Facebook、Twitter 和Reddit 為代表的科技企業，無一例外地都陷入了這種糟糕的趨勢。

相比之下，在編程的黃金時代，程序員們對內存和CPU 的限制瞭如指掌。而現如今，我們被迫生活在了一個效率極其低下、但浪費又如此誇張的泥潭里。

光是想到這些，就足以讓我們陷入無盡的惆悵。