作為一名從事遊戲設計和編程業務的個體戶，克里夫斯基（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 中，很多都涉及一些瑣碎的事情，比如原本可以簡單集成的一個位圖保存功能。
雖然要剋制住不對年輕程序員的這種行為大發雷霆，但他們本該學會這些。遺憾的是，他們沒有意識到何謂高性能或基於約束的開發。
舉個例子，當年一個僅 64Kb 的《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 的限制了如指掌。而現如今，我們被迫生活在了一個效率極其低下、但浪費又如此誇張的泥潭裡。
光是想到這些，就足以讓我們陷入無盡的惆悵。