4個費勁心思卻走向程式設計地獄的陷阱

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

優化你的程式碼、建立程式設計抽象、編寫跨平臺的應用程式，幾乎所有遵守這些戒律的程式設計師不出意外都拿著一等票去往了一個沒有休憩時間，專案總能準時完成，程式碼庫永遠不會過時，而且他們也不必寫任何文件的天堂——你懂的。

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

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

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

1. 優化程式碼
2. 建立軟體抽象
3. 使用程式設計工具
4. 建立跨平臺的應用程式

良好的意圖1：優化程式碼

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

陷阱1：過早優化

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

陷阱2：過晚優化

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

補丁

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

• 不要立即對程式碼進行優化，想一想以後有沒有其他更好更合適的時間
• 沒有正當理由不要推遲優化
• 記住20/80法則：專注於那些雖然只佔程式碼的20%，卻對結果有著80％影響的程式碼（可以使用分析器）

良好的意圖2：程式抽象

要是你仍然不得不使用goto語句來設定週期呢？或者，要是你不能夠改變你的集合大小呢？試想一下，要是你需要預留一些記憶體，複製老集合到記憶體中，新增新的元素，並釋放未使用的記憶體。完全是一個噩夢！

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

陷阱1：過於複雜

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

為了製作俄羅斯方塊，載入20個類、採用12種不同的圖案、使用你自己的DSL來解析其他的DSL、建立一個跨平臺的框架來視覺化週期性圖形，這便是過於複雜的典型例子。那些有這個美國時間堅持走這條路的程式設計師肯定以為自己是長生不死的。

陷阱2：忽視抽象

相對有經驗的程式設計師更容易被受過度複雜這個陷阱的誘捕，那麼他們經驗不足的同行們則更容易完全忽略抽象。

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

補丁

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

• 研究你的程式語言用於執行的抽象
• 不要為了使用抽象而使用抽象
• 保持簡單愚蠢（KISS原則）——在設計工作中，這意味著系統的主要目標和價值在於它的簡單，所以如果不會丟失任何重要的東西的話，那麼請忘記抽象
• 你將不需要它（YAGNI原則）——在你開始工作於一個新功能之前，先好好想想你是否真的需要它

良好的意圖3：使用程式設計工具

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

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

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

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

陷阱2：重新發明輪子

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

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

補丁

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

良好的意圖4：跨平臺

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

陷阱1：過度跨平臺

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

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

陷阱2：只適用於WIN 32

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

補丁

• 花時間搞清楚你的目標作業系統和平臺是什麼
• 準備修改部分程式碼，或者甚至寫一個單獨的版本
• 不要太執著於任何特定的平臺

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

最後，請允許我以一個“程式設計師的天堂與地獄”的故事結尾。

開發人員夢到天堂裡的程式設計師：每個人都坐在自己的電腦上，一口一口灌著咖啡，眼帶血絲……最後的時間限制正在逼近……開發人員驚醒過來，繼續睡，又夢到了地獄中的程式設計師：每個人都在自己的電腦前敲鍵盤（因為截止時間的逼近），在謾罵客戶的同時，大口大口喝咖啡，眼睛裡同樣佈滿血絲。沉睡中的開發人員於是問恰巧出現的天使：“既然如此，那麼，天堂的程式設計師和地獄的程式設計師之間的區別是什麼呢？”“區別在於，”這個天使回答，“天堂裡的程式設計師能夠按時完成任務。”

程式設計陷阱會浪費時間。如果你想在最後期限前完成任務的話，那麼請避免這些陷阱！