沒錯(cuò)，軟件行業(yè)向來崇尚年輕化。如果大家已經(jīng)擁有了自己的家庭，那么在編程領(lǐng)域已經(jīng)算是個(gè)老年人了。而如果大家已經(jīng)年過廿五甚至已過而立，那么各位未來的技術(shù)之路可能只會(huì)一路走低。

唉，自以為是的家伙并不總能完美地解決編程的技術(shù)難題。盡管他們的大腦當(dāng)中塞滿了關(guān)于最新、最流行的各類架構(gòu)、框架以及堆棧的技術(shù)細(xì)節(jié)，但他們并不具備對(duì)軟件在本質(zhì)層面為何能夠確切起效或者發(fā)生故障的實(shí)際認(rèn)知。這些經(jīng)驗(yàn)只會(huì)在我們連續(xù)數(shù)周遭遇怪異甚至莫名其妙的錯(cuò)誤之后慢慢積累并建立起來。

正如《硅谷》的觀眾們心滿意足地看著第一季第六集結(jié)尾那位少年天才最終搞砸了一切，我們這些編程界的“老者”們也同樣樂于欣賞那群視我們?yōu)?ldquo;過時(shí)之人”、但卻由于不聽前輩勸告而陷入困難的后起之秀們的沮喪表情。

本著共享精神的考量、或者也算是給年輕人的一點(diǎn)教訓(xùn)，在這里我們總結(jié)出了一些遠(yuǎn)不是憑借聰明的頭腦加上幾周的實(shí)踐就能掌握的寶貴經(jīng)驗(yàn)。順帶一提，其中很多財(cái)富只有那些需要靠?jī)晌皇M(jìn)制數(shù)字才能寫出自己年紀(jì)的老者們方可掌握。

內(nèi)存很重要

就在不久之前，我們計(jì)算機(jī)設(shè)備上的內(nèi)存容量還在以MB為計(jì)量單位而非GB。當(dāng)我組裝起自己的第一臺(tái)計(jì)算機(jī)(一臺(tái)Sol-20)時(shí)，其內(nèi)存甚至只有可 憐的KB級(jí)別。這臺(tái)設(shè)備的主板上接有約64塊內(nèi)存芯片，每一塊大約配備18個(gè)插針。我記不清楚具體數(shù)目了，但我可以肯定每個(gè)接點(diǎn)都是由自己親手焊接完成。 當(dāng)焊接任務(wù)結(jié)束后，我還得重新處理那些無法通過內(nèi)存測(cè)試的插針。

如果大家像我一樣經(jīng)歷過那段內(nèi)存是金的往昔歲月，就會(huì)意識(shí)到這一點(diǎn)點(diǎn)資源有多么寶貴。如今的年輕人們則不會(huì)那么嚴(yán)謹(jǐn)，而更傾向于“差不多得了”的態(tài)度打理內(nèi)存資源。他們會(huì)把指針搖來晃去，從不清理自己的數(shù)據(jù)結(jié)構(gòu)，這一切都是因?yàn)閮?nèi)存成本如今已經(jīng)非常低廉。他們只需要點(diǎn)擊一個(gè)按鈕，就能為自己的云實(shí)例添加16GB內(nèi)存容量。如果每個(gè)人都能如此輕松地從Amazon手中租到配備244GB巨量?jī)?nèi)存的實(shí)例，鬼才會(huì)在編程當(dāng)中認(rèn)真考慮內(nèi)存的分配問題。

然而垃圾收集機(jī)制的工作效果總會(huì)有局限，正如家長(zhǎng)不可能無限度地為小朋友們打掃房間。大家可以分配規(guī)模龐大的堆，但最終我們?nèi)匀恍枰獙?duì)內(nèi)存加以清 理。如果各位習(xí)慣了任意揮霍資源并在內(nèi)存當(dāng)中如流感一般來回穿梭，垃圾收集機(jī)制很可能出現(xiàn)體積膨脹的狀況——并最終塞滿看似充裕的224GB空間。

除此之外，虛擬內(nèi)存的興盛同樣帶來值得重視的隱患。如果我們的計(jì)算機(jī)由于內(nèi)存不足而轉(zhuǎn)向利用磁盤進(jìn)行數(shù)據(jù)交換，那么軟件的運(yùn)行速度將發(fā)生成百倍甚至上千倍的速度遞減。虛擬內(nèi)存從理論層面講確實(shí)大有可為，但在實(shí)際效果角度看卻太過緩慢。程序員們需要清醒地意識(shí)到，內(nèi)存資源在物質(zhì)極大豐富的今天仍然非常珍貴。如果缺乏這種科學(xué)的觀念，那么原本在開發(fā)階段運(yùn)行速度理想的軟件很可能在投付實(shí)踐之后遭遇速度下滑。換言之，大家的工作成果根本無法實(shí)現(xiàn)規(guī)模化拓展。近年以來，可拓展能力已經(jīng)成為一切技術(shù)方案的必要前提。因此請(qǐng)大家注意，在軟件或者服務(wù)遭遇瓶頸之前打理好內(nèi)存資源。

計(jì)算機(jī)網(wǎng)絡(luò)速度緩慢

負(fù)責(zé)市場(chǎng)營銷的員工們一直將云服務(wù)包裝成類似于計(jì)算業(yè)務(wù)領(lǐng)域的萬靈藥，在這里數(shù)據(jù)總能夠順暢無阻地往來遷移。如果大家希望在云端保存自己的數(shù)據(jù)，他 們還準(zhǔn)備好了能夠提供永久存儲(chǔ)、備份以及其它各類功能的簡(jiǎn)單Web服務(wù)產(chǎn)品——總而言之一句話，事情交給服務(wù)供應(yīng)商、您就放心吧。

在萬事拜托這方面、營銷人員的宣傳內(nèi)容的確屬實(shí)，但還有一點(diǎn)他們沒提——客戶需要等，長(zhǎng)久地、不懈地等。進(jìn)入與傳出計(jì)算機(jī)的全部流量都需要耗費(fèi)時(shí)間。相較于CPU與本地磁盤驅(qū)動(dòng)器之間的傳輸速度，計(jì)算機(jī)網(wǎng)絡(luò)一直扮演著緩慢小烏龜?shù)慕巧?/p>

編程界的前輩們可謂“生在新中國，長(zhǎng)在紅旗下”，在那艱苦的歲月里互聯(lián)網(wǎng)還根本連雛形都沒有。FidoNet會(huì)以對(duì)話方式將我們的數(shù)據(jù)路由至與可能接近目的地的其它計(jì)算機(jī)處。要想跨越國境線，大家的數(shù)據(jù)可能走得比人還慢——花費(fèi)幾天時(shí)間穿越無數(shù)吱吱作響的調(diào)制解調(diào)器。

這種痛苦的經(jīng)歷告訴他們，正確的處理方式應(yīng)該是盡可能多地以本地方式處理計(jì)算任務(wù)，并最大程度保證遠(yuǎn)方的Web服務(wù)只需要處理規(guī)模較小的最終結(jié)果。今天的程序員們很可能無法體會(huì)這些由老一輩無產(chǎn)階級(jí)開發(fā)者們從實(shí)踐中辛苦積累而來的教訓(xùn)，事實(shí)上云存儲(chǔ)給出的承諾并不可靠，而且直到最后幾毫秒內(nèi)才可以放心將任務(wù)交給云服務(wù)。

編譯器中存在漏洞

當(dāng)我們?cè)庥龉收现畷r(shí)，真正導(dǎo)致問題發(fā)生的往往并不是我們編寫出的代碼本身。我們也許忘記了對(duì)某些項(xiàng)目進(jìn)行初始化，或者沒能及時(shí)檢查某個(gè)null指針。無論實(shí)際原因是什么，每一位程序員都明白當(dāng)軟件出現(xiàn)故障時(shí)，責(zé)任必須由我們自己承諾——句號(hào)。

事實(shí)上，最令人頭痛的并不是我們自己的編程失誤。有時(shí)候責(zé)任源自編譯器或者解釋器。盡管目前的編譯器與解釋器在穩(wěn)定性方面相對(duì)可靠，但其距離完美仍有很長(zhǎng)一段道路要走。必須承認(rèn)，無數(shù)技術(shù)人員耗費(fèi)大量心血才讓今天的編譯器與解釋器擁有當(dāng)下的穩(wěn)定性水平，但將這種穩(wěn)定性認(rèn)定為理所當(dāng)然仍然不夠明智。

需要提醒大家的是，編譯器與解釋器同樣有可能發(fā)生故障，我們也應(yīng)當(dāng)在遭遇問題時(shí)將針對(duì)二者的調(diào)試工作考慮入其中。如果大家并不清楚編譯器為什么出現(xiàn) 問題，那么追尋答案的過程很可能耗時(shí)數(shù)天甚至是數(shù)周。

早在很久之前，程序員們前輩們就意識(shí)到有時(shí)候最理想的問題調(diào)試途徑并不是測(cè)試自己的代碼成果，而是將注意力集中在工具身上。如果大家習(xí)慣性地認(rèn)為編譯器本身不會(huì)出問題，而且不假思索地把責(zé)任歸咎于代碼的渲染計(jì)算過程，那么往往耗費(fèi)數(shù)天甚至數(shù)月也無法從工作中找到根本不存在的問題根源。年輕人啊，相信你們很快就能在實(shí)踐中成長(zhǎng)起來。

速度對(duì)于用戶而言極為重要

很久以前，我曾經(jīng)聽說IBM公司就可用性議題開展過一次調(diào)研，并發(fā)現(xiàn)人們的意識(shí)會(huì)在響應(yīng)時(shí)間超過100毫秒之后出現(xiàn)波動(dòng)。這一結(jié)論到底是真是假?我曾經(jīng)就此求證于搜索引擎，但互聯(lián)網(wǎng)掛掉了……而且我之后也忘記了再試一次。

經(jīng)歷了IBM大型機(jī)上那古董級(jí)綠屏應(yīng)用時(shí)代的朋友們肯定知道，IBM公司將100毫秒這一導(dǎo)致人腦意識(shí)渙散的時(shí)間分水嶺設(shè)為響應(yīng)速度閾值。有鑒于此，他們?cè)贗/O線路方面投入了大量精力。在銷售其大型機(jī)產(chǎn)品時(shí)，藍(lán)色巨人的工作人員們會(huì)以詳盡的規(guī)格列表指明設(shè)備當(dāng)中的I/O通道數(shù)量，這種作法與汽車制造商介紹自家發(fā)動(dòng)機(jī)參數(shù)時(shí)如出一轍。誠然，這些設(shè)備也會(huì)如現(xiàn)代產(chǎn)品一樣發(fā)生崩潰，但當(dāng)它們處于正常運(yùn)轉(zhuǎn)狀態(tài)時(shí)，這些數(shù)據(jù)總能通過預(yù)設(shè)通道順暢地流向終端用戶。

我曾親眼目睹過不少一位編程人員絞盡腦汁地調(diào)整其由于大量JavaScript庫以及數(shù)量總量流向?yàn)g覽器而導(dǎo)致崩潰的AJAX重量級(jí)項(xiàng)目。他們往往抱怨稱，將其陷入泥潭的緩慢創(chuàng)新成果與作為替代對(duì)象的陳舊綠屏終端相比較并不公平。

但企業(yè)中的其它部門卻應(yīng)該為此而慶幸。畢竟如今我們迎來了更美觀的圖形顯示效果并在應(yīng)用程序中包含更多色彩表現(xiàn)。毫無疑問，CSS讓一切變得更酷、更漂亮，令用戶不滿的僅僅是其緩慢的響應(yīng)速度。

真正的Web永遠(yuǎn)不可能像辦公網(wǎng)絡(luò)那樣迅捷

現(xiàn)代網(wǎng)站往往像是一只用時(shí)間壘砌而成的小豬。其往往需要數(shù)秒鐘時(shí)間將MB級(jí)別的數(shù)據(jù)從JavaScript庫當(dāng)中交付給瀏覽器。接下來，瀏覽器需要將這些多層MB數(shù)據(jù)推向JIT編譯器。如果我們能夠?qū)⑹澜绶秶鷥?nèi)全部jQuery重新編譯帶來的時(shí)耗加以累積，其總長(zhǎng)很可能達(dá)到數(shù)萬甚至上百萬年。

樂于使用基于瀏覽器的各類工具的程序員們往往會(huì)犯下一類常見錯(cuò)誤——以無處不在的方式肆意濫用AJAX。這一切在辦公環(huán)境的演示過程中都能順利完成，畢竟在這類條件下服務(wù)器本身就位于桌子后面的柜子上。

有時(shí)候“服務(wù)器”也會(huì)運(yùn)行在本地主機(jī)當(dāng)中。當(dāng)然，文件能夠在彈指一揮間到達(dá)指定位置，運(yùn)行的整個(gè)過程都非常順暢、甚至老板在屋角進(jìn)行測(cè)試時(shí)也能應(yīng)對(duì)自如。

不過當(dāng)用戶身處DSL連接環(huán)境下或者需要通過一座已然過載的信號(hào)塔以蜂窩網(wǎng)絡(luò)進(jìn)行路由時(shí)，結(jié)果又會(huì)如何?他們需要耗費(fèi)大量時(shí)間等等庫內(nèi)信息的交付。如果無法在數(shù)毫秒當(dāng)中順利抵達(dá)，他們往往會(huì)憤而在TMZ上發(fā)表文章大發(fā)牢騷。

算法的復(fù)雜程度至關(guān)重要

在某個(gè)項(xiàng)目當(dāng)中，我遇到了與《硅谷》居住中Richard面臨的同一個(gè)難題，而我也與他一樣、把求助的目光投向了一位尚未到飲酒年齡但已經(jīng)對(duì) Greasemonkey的前世今生極為熟悉的朋友身上。他對(duì)我的代碼進(jìn)行了重寫，并把結(jié)果發(fā)還給我。在閱讀了各項(xiàng)變更之后，我意識(shí)到他僅僅是將代碼內(nèi)容 變得更加精致，但同時(shí)也把算法的復(fù)雜程度由0(n)提升到0(n^2)。他堅(jiān)持將數(shù)據(jù)放在列表當(dāng)中以實(shí)現(xiàn)匹配，這么做看起來確實(shí)很漂亮、但卻會(huì)隨著n值的 提升而導(dǎo)致代碼運(yùn)行速度越來越慢。

算法復(fù)雜性議題在高校的計(jì)算機(jī)科學(xué)課程當(dāng)中已經(jīng)得到了詳盡的解讀。然而，很多出身科班、憑借著聰明才智在周末自學(xué)掌握Ruby或者CoffeeScript的年輕人們根本沒能深入領(lǐng)會(huì)其精神。

復(fù)雜性分析可能看似一種極為深?yuàn)W的理論性事務(wù)，但其會(huì)隨著項(xiàng)目規(guī)模的變化而展現(xiàn)出完全不同的面貌。當(dāng)n值較小時(shí)，一切都能夠輕松實(shí)現(xiàn)。特別是在內(nèi)存容量充裕時(shí)，代碼將以令人滿意的速度得以執(zhí)行，這時(shí)即使糟糕的算法也能夠在測(cè)試中得以通過。然而當(dāng) 用戶倍增再倍增時(shí)，那些包含有0(n^2)甚至0(n^3)的算法會(huì)讓使用者陷入無盡等待的噩夢(mèng)。

當(dāng)我詢問這位天才少年，能否把匹配流程轉(zhuǎn)化為一條二次算法時(shí)，他撓了撓頭。他根本不知道我在說些什么。后來，我利用一套散列表取代了他的清單，一切也就此回歸順暢。不過時(shí)至今日，我想他一定已經(jīng)老到到能夠理解這個(gè)話題的程度了。

庫有可能糟糕透頂

那些編寫庫的技術(shù)人員并不總是關(guān)注我們這些普通使用者的利益與訴求。他們確實(shí)在努力幫忙，但其關(guān)注重點(diǎn)往往集中在為整個(gè)世界作出貢獻(xiàn)身上——而非我 們?nèi)粘Ｃ媾R的小小難題。他們最終打造出的往往是一把能夠解決多種不同版本問題的瑞士軍刀，而非針對(duì)當(dāng)前問題作出深度優(yōu)化的解決方案。庫項(xiàng)目的工程技術(shù)與編碼水平毋庸置疑，但運(yùn)行速度卻可能不堪恭維。

如果大家不在這方面多加注意，那么庫本身很可能把我們的代碼成果拖進(jìn)速度緩慢的泥潭，而各位對(duì)此甚至一無所覺。我曾經(jīng)請(qǐng)一位年輕的程序員幫我調(diào)整代碼成果，因?yàn)槲覍懥耸写a來從字符串中提取字符。

“我可以用一條正則表達(dá)式與一行代碼完成同樣的任務(wù)，”他自信地表示。“從十行到一行，這就是看得見、摸得著的改進(jìn)。”但他并沒有意識(shí)到，他這一行代碼在每一次進(jìn)行正則表達(dá)式調(diào)用時(shí)，都需要經(jīng)歷解析與重新解析的過程。他單純認(rèn)為自己編寫的是一行代碼，而我這是十行代碼，因此他比我水平高到不知道哪里去了。

庫與API在適當(dāng)運(yùn)用的前提下能夠發(fā)揮巨大的作用。但如果以內(nèi)部循環(huán)的方式加以使用，那么他們完全可能對(duì)速度產(chǎn)生破壞性的影響——而當(dāng)事人往往還完全摸不著頭腦。

文章轉(zhuǎn)載自微信公眾號(hào)“一斑”(ID: yiban51CTO)