北京
設想這樣一個場景：1982年，一個程序員坐在Commodore 64前，整個機器的內存只有64KB。這64KB不是他抱怨的理由，而是他揮灑才華的畫布。他要讓角色在屏幕上流暢移動，要處理碰撞檢測，要放進幾段旋律——每加一個字節都需要仔細掂量。時鐘周期更是稀缺得像沙漠里的水。就在這種近乎殘酷的束縛里，誕生了《瘋狂礦工》《國際空手道》等影響一代人的作品。那個年代，效率不是一種美德，而是生存的唯一方式。
轉眼四十年，我們進入了一個“富饒”到令人不安的開發時代。點幾下鼠標，幾GB內存就分配好了；云硬盤空間仿佛沒有盡頭；CPU周期像一條永不停歇的河流。工程師搭建起龐大得驚人的系統，其規模在幾十年前簡直不可想象。這種前所未有的資源獲取，確實給創新裝上了加速器。但同時，一個讓人不太舒服的問題也浮現出來：我們在這片豐饒之中，是否正在丟掉過去那種定義工程才華的銳利？我們是不是變得只會依賴堆硬件、上算力，而忘了那些由緊迫感催生出來的精致和巧妙？
正方會說，如此充沛的資源恰恰推動了軟件工程的黃金時代。沒有彈性擴容、沒有大內存，機器學習模型就無法針對海量數據做訓練，微服務架構也撐不起如同網絡游戲或電商大促的峰值壓力。按照這一派觀點，在成本可控的前提下，用“蠻力”換時間、用硬件換開發效率，本身就是一種現代工程智慧。不能簡單把過去那一套上升為絕對真理。
反方卻提醒我們，失去約束感正在讓代碼變得臃腫和遲鈍。同樣是處理一份大數據集，今天的開發習慣往往是：先把所有數據一口氣讀進內存，再新建一個中間列表存放過濾后的結果，最后再執行求和——三部曲下來，內存占用可能是原始數據的數倍。當數據量從一萬行膨脹到十億行時，這種做法可能直接讓程序崩潰。在資源無虞的錯覺下，我們常常忘記了，任何機器的物理能力終究存在邊界。
我們看看一個典型場景：假設要計算從0到10億之間所有偶數的總和。一種“資源無感”的思路是，先創建一個包含全部10億個整數的列表，再從里面挑出偶數放入新列表，最后加總。在Python這類語言里，這相當于顯式構造兩個超大規模列表，內存占用高到不切實際。而另一種思路，僅僅承認一條樸素前提——內存不是無限的——就能扭轉局面。利用Python的range()惰性遞進數字，根本不必生成完整列表，直接判斷每個數是否為偶數并累加到結果變量里，整個過程中占用的內存幾乎可以忽略。一樣的答案，完全不同的資源消耗曲線。
這兩種寫法并不是在爭論哪種語言更高級，而是在展示工程師面對約束時的下意識選擇。當默認環境似乎無限時，我們會不假思索地選擇“先保存所有數據”的路徑；而一旦把約束重新擺回桌面，效率思維就被激活。其實，那個曾經只有64KB的世界，并沒有要求我們變回苦行僧，它只是在提醒我們：所謂工程天才，常常就是在一組清晰的限制條件下，找到那個優雅到讓人贊嘆的解法。即便在今天，把“每個字節和每條指令都有成本”的念頭植入腦海，仍舊能逼出更好的架構、更干凈的代碼和更可持續的系統。
這種從稀缺中得來的肌肉記憶，不應該因為資源的充裕而徹底松弛。它不是要我們拒斥云原生或彈性伸縮，而是讓我們在分配幾十個G內存時多一點思量，在引入一堆中間狀態時停下來問問自己：“這里還能更輕一點嗎？” 有意識地在豐腴時代保留一份約束感，大概就是讓工程師持續長出銳氣的那塊磨刀石。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
