程式設計前輩留下的五條經典傳世心得

　　雖然年輕就是本錢，不過多年經驗能讓我們編寫出最卓越的程式碼。

　　在矽谷，企業招聘人才時總會面臨著兩難局面。考慮到過去幾年中出現的歧視訴訟案，人力資源方面往往不敢詢問申請者的年齡。為了解決問題，他們只好想出一些只有老鳥們才懂的梗，希望藉此瞭解對方的從業時間。

　　計算機行業永遠充斥著新的技術與模式，當然也包括新晉程式設計師。不過必須承認，舊有技術仍然廣泛存在。大型機之類的古董級產物可能已經無法登上頭條新聞，但其還在運轉不休。事實上，目前的Cobol從業者數量仍達到Ocaml、Erlang以及Haskell從業者總和的五倍。

　　年齡歧視非常普遍，在一定程度上也可以理解。年輕的程式設計師們不受舊觀念束縛，但老鳥們則更加專注且勤奮——至少不會把大量精力分散到自己的PC及智慧手機上。

　　事實上，擁有多年開發經驗的程式設計師曾經經歷過一切親自動手的時代。那時候根本沒有什麼整合化開發環境、優化編譯器乃至持續整合方案，想要的全部工具都得自己想辦法解決。毫無疑問，這是年輕一代所想象不到的。

　　因此我們將在今天的文章中共同瞭解由程式設計前輩們傳遞，並應由新一代新鮮血液繼續傳承的五項心得。

　　彙編

　　不到50歲的從業者們可能根本搞不清mov ah, 09h或者cmp eax, ebx這樣的語句。如今的程式設計師們以為計算機天然需要使用大括號來實現程式碼塊分隔，但實際上最初分隔效果是依靠以上表達實現的。即使是瞭解Java或者C應當被翻譯為二進位制形式的朋友，也往往很少或者完全沒有實際操作經驗。

　　老程式設計師們曾拿出大量時間編寫彙編程式碼，這也是原始填制機器碼與人類可讀版本之間的第一道橋樑。當然，這並不是說彙編仍是一項必須掌握的技術。由於極為冗長且存在大量重複內容，我們很可能在處理組合語言時犯下錯誤。如今的編譯器已經足以識別各類複雜且仍有優化空間的模式;一部分編譯器開發者甚至堅信自己的工具能夠編寫出水平高於手動構建的程式碼成果。

　　也許確實如此，但學習組合語言的益處在於，我們能夠藉此瞭解計算機的工作方式。高階語言帶來大量便捷的標準操作設定，例如連線字串，但這同時也帶來了新的陷阱——程式設計師們開始誤以為“加號”在連線兩個整數以及對兩個整數進行相加時，佔用的時長是相同的。實際情況並非如此。操作的耗時要遠高於普通連線，而理解彙編程式碼以及JMP(jump)操作原理的程式設計師能夠順利做出正確的選擇。

　　另外，理解物件如何在記憶體中打包並載入至CPU能夠幫助我們降低遲緩程式碼的出現機率。雖然接觸過組合語言的從業者們如今可能不再記得x86程式碼的編寫方式，但他們仍然具備良好的本能，足以發現一切可能導致程式碼效率低下的狀況。

　　聲與光

　　很久以前，一位程式設計師告訴我，他對Unix極為厭惡?為什麼?因為他在剛剛入行時，使用的是Altair或者Sol 20這樣的單使用者微機，其一次只能處理一個程式碼塊。

　　“Unix計算機總是在同時處理多項任務，”他告訴我。“你會聽到磁碟突然就轉動起來，但卻不知道是怎麼回事。”

　　真正困擾他的是，他失去了對計算機當前運作目的的判斷能力。在現代計算機當中，沒人知道這臺裝置究竟在幹什麼——因為其中包含著數不清的軟體層，並執行在四核甚至是八核CPU當中。病毒與蠕蟲亦可潛伏於其中，而使用者完全感覺不到由此帶來的效能影響。

　　前輩程式設計師們仍然習慣於通過視覺與聽覺判斷問題，幫助他們理解並除錯程式碼。他們觀看資料經過時RJ-45乙太網插孔的閃爍，聆聽磁軌改變時硬碟的響聲。他們甚至能夠藉此意識到不同分頁間的差別，甚至藉此瞭解裝置在對索引的哪部分進行讀寫。

　　這些線索的價值正在逐漸消失，SSD以及無線路由器的大量普及讓它們不復存在。但只要智慧手機上還有小小的指示標記提醒資料流通，這種敏銳的嗅覺就仍有用武之地。

　　資料大爆炸

　　遙想當年，程式設計師們需要將8個不同的布林值轉化為1個位元組。他們對每個儲存位都極為珍視，因為當初的容量資源真的非常有限。

　　現代資料結構則充斥著浪費與隨意。XML中的各類標籤名稱極長，且每個名稱都會以額外的斜槓作為結束標記。JSON相對更為進步，因為其無需關閉標籤——而只需要大括號，這就讓其身材更苗條一點。然而，JSON的標籤與字串內也存在著眾多不必要的引號。

　　好訊息是，現代壓縮演算法能夠顯著降低資料結構所佔用的空間。但壓縮並不能徹底解決問題，而前輩程式設計師們卻知道如何從起步階段避免這種浪費。也正因為如此，MS-DOS 3.0作業系統仍有32MB，這意味著其最大空間佔用量也不會超過3200萬個位元組。

　　事實上，MS-DOS 3.0誕生於上世紀八十年代初，七十年代的程式碼在精簡程度上更勝一籌。而六十年代的程式碼——簡直就是藝術品。

　　二進位制數學

　　對bit位的測試與調整並非出於好奇，而是一種必要。某些操作的執行速度太慢，迫使程式設計師們尋求更理想的方式加以解決。最典型的例子就是除以二相當於在二進位制中將小數點向右移一位，而除以十則為十進位制中將小數點向右移一位。

　　相較於正常除法，CPU在處理數位移動時速度明顯更快。出色的程式設計師會利用這種優勢加快程式碼執行速度，而非笨笨地坐等乘法與除法處理。

　　但如今這種良好的思維方式正在逐漸消失，強大的處理效能足以承載我們的揮霍。不過必須強調的是，這種敏銳的本能在現代開發工作中仍然有著重要價值。

　　細節累加即為結果

　　在多數早期處理器中，某些操作的時耗要遠高於其它操作。在初代8086處理器中，數學除法要耗費80到190個時鐘週期，而將兩個數字相加則只需要耗費3個時鐘週期。即使當時的CPU主頻已經達到5 MHz，大量操作疊加起來也會造成巨大的處理時長差距。

　　前輩程式設計師們很清楚每行程式碼或者每項指令的執行時間差別，他們也明白計算資源是如此寶貴，需要認真規劃與管理。錯誤的操作型別將大大延長處理時間，而錯誤的資料型別也會帶來同樣的後果。一旦使用錯誤的資料結構，我們辛苦打造的程式將瞬間成為垃圾。

　　很多年輕一代認為CPU能夠在瞬間完成幾乎無限量的計算，但前輩們則很清楚CPU是如何一步步向使用者交付結果的。多年以來，經驗豐富的程式設計師對自己的程式碼細節進行研究、除錯與重新研究，也正是這些積累讓他們成為行業中的翹楚。因此，請抱著敬畏的心對待自己指尖流出的程式碼——它們正一步步塑造著我們的職業生涯。

　　作者：中國大資料

　　連結：http://toutiao.com/a6275115274681549057/