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