優(yōu)化你的代碼、創(chuàng)建編程抽象、編寫跨平臺的應(yīng)用程序，幾乎所有遵守這些戒律的程序員不出意外都拿著一等票去往了一個沒有休憩時間，項目總能準時完成，代碼庫一直不會過時，而且他們也不必寫任何文檔的天堂——你懂的。

　　但是，要是情況不是這樣的呢？要是那些技術(shù)將你帶往的不是天堂，而是地獄呢？要是并非死后到達地獄，反而是現(xiàn)在呢？要是地獄充滿了無數(shù)的不眠之夜，超出的期限，破碎的自尊心和狂怒的項目經(jīng)理呢？我們更多地將到達地獄的原因歸咎于這樣一個事實，當涉及到一些具體——和常見——的情況時，那些戒律將成為坑死程序員的陷阱。更糟的是，你甚至不會意識到這一點。稀里糊涂，游戲就over了。

　　這些陷阱之所以陰險，是因為它們讓你覺得你正在往正確的道路上走。但其實不然。這些坑死程序員的陷阱，簡而言之就是，當你做一些你認為應(yīng)該做的事情時，但卻沒有用你應(yīng)該做的方式。

　　這篇文章探討了可以把程序員的生活變成人間地獄的4個正確做法。

　　1.優(yōu)化代碼

　　2.創(chuàng)建軟件抽象

　　3.使用編程工具

　　4.創(chuàng)建跨平臺的應(yīng)用程序

　　良好的意圖1：優(yōu)化代碼

　　優(yōu)化代碼本身沒有錯。相反：表現(xiàn)力強的，效率高的，和資源節(jié)約型的代碼是一個成熟大牛的標志。不過……希望你不會掉進任何優(yōu)化的陷阱。

　　陷阱1：過早優(yōu)化

　　過早優(yōu)化是一個典型的程序員陷阱。即使是很博學和很有經(jīng)驗的程序員也會掉入這個陷阱。了解處理器是工作的以及知道強大的算法，可以幫助編寫出效率高且優(yōu)美的代碼。然而，那并不總是必要的：有時它甚至是一件壞事。因為你很難猜出薄弱點會在哪里，這意味著在得到它如何工作的詳細經(jīng)驗證據(jù)之前，試圖優(yōu)化代碼會導致問題復(fù)雜、有bug的代碼。更不要說浪費在優(yōu)化中的時間了。

　　陷阱2：過晚優(yōu)化

　　有時候，程序員為了避免過早優(yōu)化，反而掉進了過晚優(yōu)化的陷阱，過晚優(yōu)化通常發(fā)生在認為優(yōu)化是項目最后階段的地方。還等什么呢？過晚的優(yōu)化可能會讓你不得不重寫至少三分之一的代碼。更糟糕的是，你可能還沒法寫出另一塊干凈的，可工作的代碼。浪費了時間，錯過了截止期限，迷失了自己。

　　補丁

　　但是何時優(yōu)化太早何時優(yōu)化又變得太晚是不容易弄清楚的。所以睜大你的眼睛，隨時保持警惕！

　　•不要立即對代碼進行優(yōu)化，想一想以后有沒有其他更好更合適的時間

　　•沒有正當理由不要推遲優(yōu)化

　　•記住20/80法則：專注于那些雖然只占代碼的20%，卻對結(jié)果有著80％影響的代碼（可以使用分析器）

　　良好的意圖2：程序抽象

　　要是你仍然不得不使用goto語句來設(shè)置周期呢？或者，要是你不能夠改變你的集合大小呢？試想一下，要是你需要預(yù)留一些內(nèi)存，復(fù)制老集合到內(nèi)存中，添加新的元素，并釋放未使用的內(nèi)存。完全是一個噩夢！

　　抽象可能是編程中非常好的禮物。但是如果涉及我們將要討論的這些情況，就另當別論了。

　　陷阱1：過于復(fù)雜

　　有些人認為，專門的函數(shù)是弱者所為，這就是為什么他們要編寫不管情況如何都可以完成任務(wù)的zui大化的廣義函數(shù)。在著手于主要功能之前，他們先寫了一個通用框架。這樣做為什么不好？這么說吧，他們的代碼只有30％被使用，而且沒有人會需要一個通用的功能。所以這樣費心費力值得嗎？

　　為了制作俄羅斯方塊，加載20個類、采用12種不同的圖案、使用你自己的DSL來解析其他的DSL、創(chuàng)建一個跨平臺的框架來可視化周期性圖形，這便是過于復(fù)雜的典型例子。那些有這個美國時間堅持走這條路的程序員肯定以為自己是長生不死的。

　　陷阱2：忽視抽象

　　相對有經(jīng)驗的程序員更容易被受過度復(fù)雜這個陷阱的誘捕，那么他們經(jīng)驗不足的同行們則更容易完全忽略抽象。

　　往往在程序員剛開始使用一種新的編程語言來工作的時候，就是這個陷阱虎視眈眈特別容易捕獲獵物的時候。由于判定學習新語言的抽象會花費太多時間，所以就降低了其在優(yōu)先事項清單上的地位。另一方面，舉個例子，當你從C轉(zhuǎn)移到C++，或當你從一種操作語言轉(zhuǎn)移到Haskell語言時，忽略迭代器會嚴重限制你。內(nèi)置的語言工具和第三方的庫和框架，實際上通過使得代碼更短，更簡單，更快速而改善了代碼。

　　補丁

　　這里有一些需要謹記的事情。

　　•研究你的編程語言用于執(zhí)行的抽象

　　•不要為了使用抽象而使用抽象

　　•保持簡單愚蠢（KISS原則）——在設(shè)計工作中，這意味著系統(tǒng)的主要目標和價值在于它的簡單，所以如果不會丟失任何重要的東西的話，那么請忘記抽象

　　•你將不需要它（YAGNI原則）——在你開始工作于一個新功能之前，先好好想想你是否真的需要它

　　良好的意圖3：使用編程工具

　　現(xiàn)在有無數(shù)的工具和庫，要么它們本身可以幫助完成任務(wù)，要么可以讓工作變得更輕松。了解如何使用這些工具是技能集合的關(guān)鍵因素。當然，這里也有一些陷阱是需要警惕的。

　　陷阱1：“我需要的一切已經(jīng)有人寫好了”

　　那些覺得一切都已經(jīng)有人寫好了的程序員，喜歡使用他們那套現(xiàn)成的第三方工具。有時，而且特別是那些有經(jīng)驗的程序員，總是伴隨著盲目地迷信于其他人的代碼（他們下意識地認為在某個地方有一群高智商的家伙編寫了毫無瑕疵的庫）。但是，這是否真的值得你下載一個30+MB的庫只因為一個小小的梅森旋轉(zhuǎn)算法？你是否真的需要boost、Qt和STL來寫“Hello,world!”？其他人寫的代碼并不一定好，并且我也不愿意去調(diào)試別人寫的代碼。如果你發(fā)現(xiàn)自己在IDE中沒有自動更正就無法寫好一行代碼，那么說明你已經(jīng)身陷這個陷阱而不自知。

　　每隔一段時間，程序員必須能夠推倒重來，雖然……這也會成為陷阱。

　　陷阱2：重新發(fā)明輪子

　　重新發(fā)明輪子的通常是那些缺乏經(jīng)驗或正在學習新語言半途中的程序員。他們重新寫了很多函數(shù)，忘記了第三方庫中已有的相同功能的函數(shù)。他們相信，他們的語言和標準庫已經(jīng)具備了所有他們可能需要的東西，而自動更正工具，例如IDE則是為那些天才準備的，調(diào)試器和分析器則時刻等待著那些不記得自己的代碼是如何工作的人。

　　還需要我提一提這個陷阱出現(xiàn)的次數(shù)嗎？不僅如此，重新發(fā)明的輪子往往新不如舊：新的解決方案比標準方案要差得多。這和測試和教育項目無關(guān)，當然，有時候重新發(fā)明輪子是必不可少的，甚至是有益的：這適用于不需要常規(guī)項目的地方。

　　補丁

　　你必須知道如何使用zui新的工具，以及如何正確使用這些工具。但另一方面，你不能完全依賴他們。

　　良好的意圖4：跨平臺

　　理想的應(yīng)用程序應(yīng)該在許多操作系統(tǒng)和設(shè)備上都工作良好，對吧？是的，只要這個標準不會給你帶來麻煩。

　　陷阱1：過度跨平臺

　　“不要坐在這把椅子上：它是給大家看的，不是讓你坐的”（在一家現(xiàn)代藝術(shù)博物館中，其椅子藝術(shù)品上的告示上如此寫道）。那椅子就是“超級萬能跨平臺”應(yīng)用程序的形象比喻。它不會正常工作于任何原先計劃設(shè)計的操作系統(tǒng)上，在電腦、平板電腦和智能手機上同樣如此。那么，為何會如此呢？類似于這樣的應(yīng)用程序是一些經(jīng)驗不足或過于自信的開發(fā)人員所編寫的，他們相信自己創(chuàng)建的代碼可以工作在所有的平臺上而無需任何自定義。它們也是由一些懶惰的開發(fā)人員編寫的，自以為可以運行在盡可能多的操作系統(tǒng)和平臺上，而不必花時間移植。

　　可能也會有例外。但是，大多時候試圖迫使應(yīng)用程序可工作于所有的操作系統(tǒng)和所有設(shè)備，只會讓你看著森林而找不到樹木。然后，你只能茫茫然地帶著上面一段我們提到的那把跨平臺椅子離開。

　　陷阱2：只適用于WIN32

　　另一個要避免的陷阱是發(fā)布只能和特定操作系統(tǒng)、特定鼠標、特定鍵盤和特定虛擬現(xiàn)實頭盔一起工作的軟件。你想要為每個目標平臺重寫所有或大部分的代碼嗎？有人強迫你為你的編譯器/解釋器使用不同尋常的擴展嗎？你是故意編寫很難轉(zhuǎn)移的代碼嗎？那么你被困在了這個陷阱中。

　　補丁

　　•花時間搞清楚你的目標操作系統(tǒng)和平臺是什么

　　•準備修改部分代碼，或者甚至寫一個單獨的版本

　　•不要太執(zhí)著于任何特定的平臺

　　有沒有可能避免每一個陷阱呢？我不確定，但我知道的是，總有辦法讓你走出這些陷阱。凡事預(yù)則立，對吧？

　　編程陷阱會浪費時間。如果你想在deadline前完成任務(wù)的話，那么請避免這些陷阱