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

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

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

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

　　1.優化代碼

　　2.創建軟件抽象

　　3.使用編程工具

　　4.創建跨平臺的應用程序

　　良好的意圖1：優化代碼

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

　　陷阱1：過早優化

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

　　陷阱2：過晚優化

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

　　補丁

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

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

　　•沒有正當理由不要推遲優化

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

　　良好的意圖2：程序抽象

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

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

　　陷阱1：過于復雜

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

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

　　陷阱2：忽視抽象

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

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

　　補丁

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

　　•研究你的編程語言用于執行的抽象

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

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

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

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

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

　　陷阱1：“我需要的一切已經有人寫好了”

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

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

　　陷阱2：重新發明輪子

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

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

　　補丁

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

　　良好的意圖4：跨平臺

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

　　陷阱1：過度跨平臺

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

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

　　陷阱2：只適用于WIN32

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

　　補丁

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

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

　　•不要太執著于任何特定的平臺

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

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