原文：https://programmers.blogoverflow.com/2012/08/20-controversial-programming-opinions/

翻譯：碼中人

配圖：碼中人

1. 業餘時間不以程式設計為樂的程式設計師，永遠不會像以程式設計為樂的程式設計師一樣優秀。

我認為即使是最聰明、最有天賦的人也不會成為真正優秀的程式設計師，除非他們把它當成比工作更重要的事情。也就是說，他們在業餘時間做一些小專案，或者只是在業餘時間搞很多不同的語言和想法。

作者 rustyshelf

2. 單元測試不會幫助你寫出好的程式碼。

有單元測試的唯一原因是為了確保已經能用的程式碼不會出錯。先寫測試，或者先寫程式碼再寫測試都很可笑的。如果你先寫測試再寫程式碼，你甚至不知道邊緣情況是什麼。你可能會有透過測試的程式碼，但在不可預見的情況下仍然失敗。而且，好的開發人員會保持較低耦合，這將使新程式碼的新增不太可能導致現有的東西出現問題。

3. 你唯一應該一直使用的 “最佳實踐 “就是 “開動自己的腦筋”。

太多的人都趕時髦，試圖把方法、模式、框架等強加到不值得的事情上。僅僅因為某些東西是新的，或者因為某個受人尊敬的人有一個觀點，並不意味著它適合所有的人。

4. 大多數程式碼中的註釋其實是一種垃圾程式碼的重複。

我們花了大部分時間來維護別人（或我們自己）寫的程式碼，而拙劣的、不正確的、過時的、誤導性的註釋一定是程式碼中最令人討厭的人工製品的榜首。我想最終很多人都會把它們忽略掉，尤其是那些花盒怪獸。更好的做法是專注於使程式碼可讀，必要時重構，並儘量減少習語和怪癖。另一方面，許多課程教導說註釋幾乎比程式碼本身更重要，導致下一行給 invoiceTotal 增加一個註釋的風格。

5. “上網查查 “未嘗不可!

是的，我知道這觸犯了一些人的利益，他們多年緊張的記憶和/或光榮的一摞程式設計書籍，開始被一個任何人都可以在幾秒鐘內訪問的資源所取代，但你不應該對使用它的人持反對態度。我經常聽到google解決問題的答案是批評的結果，這真的是沒有意義的。

首先，必須承認，每個人都需要材料來參考。你不是什麼都懂，你也需要查資料。承認了這一點，你從哪裡得到的資料真的重要嗎？你是在書上查的，還是在谷歌上查的，還是從一隻會說話的青蛙那裡聽到的，這重要嗎？不，一個正確的答案就是一個正確的答案。重要的是你理解了這些材料，把它作為成功的程式設計方案的手段，並且客戶/你的僱主對結果滿意。

6. 不是所有的程式設計師受到合理待遇。

很多時候，管理者認為開發人員A等效於開發人員B，只是因為他們的經驗水平相同等等。實際上，一個開發人員的業績可能是另一個開發人員的10倍甚至100倍。談論這個問題在政治上是有風險的，但有時我覺得應該指出，即使幾個團隊成員看起來技術相當，但情況並不總是如此。我甚至看到過這樣的情況：主要開發人員 “無可奈何”，而初級開發人員做了所有的實際工作–雖然我相信他們得到了讚美。

7. 我不明白為什麼人們認為Java是大學裡最好的 “第一 “程式語言。

其一，我認為第一門程式語言應該是這樣的，它強調的是學習控制流和變數，而不是物件和語法。其二，我相信沒有在C / C++中除錯記憶體洩漏經驗的人不能完全理解Java帶來的東西。另外，自然的進展應該是從 “我怎麼能做這個 “到 “我怎麼能找到能做那個的庫”，而不是相反。

作者 Learning

8. 如果你只懂一門語言，不管你對它有多精通，你都不是一個偉大的程式設計師。

似乎有一種態度認為，一旦你真的擅長C#或Java或其他任何你開始學習的語言，那麼這就是你所需要的。我不這樣認為，因為我所學過的每一門語言都教會了我一些關於程式設計的新東西，這些知識再反哺工作。我認為，任何一個人如果把自己限制在一門語言上，就永遠不會有好的表現。這也向我表明了某種缺乏好奇心和嘗試的意願，這不一定符合我期望在一個真正優秀的程式設計師身上找到的品質。

9. 偶爾寫一些垃圾程式碼是可以的。

有時候，為了完成一個特定的任務，只需要一段快速而骯髒的垃圾程式碼。模式，ORM，SRP，不管是什麼……在控制檯搞一下或簡單寫個Web應用程式，寫一些內聯SQL，然後快速地完成需求。

10. 列印語句是除錯程式碼的有效方法。

11. 你的工作就是讓自己失業。

當你為你的僱主編寫軟體時，你所建立的任何軟體都要以這樣的方式編寫，即它可以被任何開發人員拾起並以最小的努力理解。它設計得很好，寫得清晰一致，格式乾淨，在需要的地方有文件，每天按預期構建，檢查到倉庫，並有適當的版本。

如果你被公交車撞了，下崗，被解僱，或者走下神壇，你的僱主應該能夠在一瞬間通知你替換你，下一個人可以介入你的角色，拿起你的程式碼，頂多一週內就可以開始執行。如果他或她做不到這一點，那你就太失敗了。有趣的是，我發現，有了這個目標，我對僱主來說更有價值。我越是努力成為一次性的人，對他們來說就越有價值。

12. Getters和Setters被過度使用。

我見過數以百萬計的人聲稱公共欄位是邪惡的，所以他們將其私有化，併為所有欄位提供getter和setter。我相信這與將欄位公開幾乎是一樣的，如果你使用執行緒（但一般情況下不是這樣）或者如果你的訪問者有業務/展示邏輯（至少是一些 “奇怪 “的東西），也許會有一點不同。我並不贊成公共欄位，但反對為每個欄位建立一個getter/setter（或Property），然後聲稱這樣做是封裝或資訊隱藏……哈哈！我認為，這是不對的。

13. 別拿SQL不當程式碼。

也就是說，就像你的C#、Java或其他喜歡的物件/程式語言一樣，開發一種可讀和可維護的格式化風格。我討厭看到馬虎的自由格式化的SQL程式碼。如果你在頁面上看到兩種樣式的大括號時都會尖叫，那麼當你看到自由格式化的SQL或模糊或混淆JOIN條件的SQL時，你為什麼或為什麼不尖叫呢？

14. UML圖被高度高估了。

當然有一些有用的圖，比如複合模式的類圖，但是很多UML圖完全沒有價值。當然也有一些有用的圖，比如複合模式的類圖，但是很多UML圖完全沒有價值。

15. 可讀性是最重要的。

可讀性甚至比正確性更重要。如果它是可讀的，它就很容易修復。也容易最佳化，容易改變，容易理解。而且希望其他開發者也能從中學到一些東西。

16. XML被高估了。

我認為有太多的人從未經過思考，就跳上了XML的浪潮……XML用於網路的東西是很好的，因為它是為它設計的。否則，我認為一些問題定義和設計思想應該優先於任何使用它的決定。

17. 軟體開發也只是一份工作。

我很喜歡軟體開發。在過去的幾年裡，我寫了一個關於這個主題的系列部落格。我在這裡花了足夠多的時間，有超過5000個信譽點。我在一家初創公司工作，每週工作時間通常為60小時，收入比我作為一個承包商要少得多，因為團隊很棒，工作也很有趣。

但本質而言，這只是一份工作。它的重要性排在很多事情之下，比如家庭、我的女朋友、朋友、幸福等，如果有無限的現金供應，我肯定選擇做的其他事情之下，比如騎摩托車、帆船遊艇或者滑雪板。我覺得有時候很多開發者忘記了，開發只是讓我們擁有生活中更重要的東西（透過做我們喜歡的事情來擁有），而不是作為最終目標本身。

18. 如果你是一個開發人員，你應該會寫程式碼。

(這不是廢話嗎，看完我不太相信)

去年我做了不少面試，我面試的部分應該是測試大家的思維方式，以及如何在白板上實現簡單到中等的演算法。我一開始的問題是這樣的。

考慮到Pi可以用函式4*(1 – 1/3 + 1/5 – 1/7 +… )來估計，更多的項會帶來更高的精度，請寫一個函式，計算Pi的精度達到小數點後5位。

這是一個應該讓你思考的問題，但對於一個經驗豐富的開發人員來說，應該不是遙不可及的問題（用大約10行C#語言就可以回答）。然而，我們的許多（據說是經過機構預選的）候選人甚至無法開始回答這個問題，甚至無法解釋他們如何去回答這個問題。所以過了一段時間後，我開始問一些比較簡單的問題，比如。

假設圓的面積是Pi乘以半徑的平方，寫一個函式來計算圓的面積。

令人驚訝的是，超過一半的考生不會用任何語言寫這個函式（我可以讀懂大多數流行的語言，所以我讓他們使用任何他們選擇的語言，包括虛擬碼）

我們有 “C#開發人員 “不能用C#寫這個函式。我對此感到很驚訝。我一直認為，開發人員應該能夠寫程式碼。現在看來，這是個有爭議的觀點。當然，在面試候選人中也是如此

19. 設計模式對好設計的傷害大於幫助。

軟體設計，尤其是好的軟體設計太多變了，無法用模式來有意義地捕捉，尤其是人們能真正記住的模式數量很少–而且這些模式太抽象了，人們真正能記住的不只是少數幾個。所以它們沒有什麼幫助。而另一方面，太多人迷戀這個概念，並試圖將模式應用到各個地方–通常，在所產生的程式碼中，你無法在所有（完全沒有意義的）Singletons和Abstract Factories之間找到實際的設計。

20. 程式碼越少越好

如果使用者說 “就這（麼點）？”，沒有體現你的工作量，那就是做對了。相信我，你要把這當成對你的最高讚譽。