在StackOverflow上有這樣的一個貼子《What’s your most controversial programming opinion?》，中文的意思是“你認為最受爭議的程式設計觀點有哪些？”，這個帖子是Jon Skeet在2009年1月提出，Jon Skeet是C#社群大名鼎鼎的人物，多年微軟MVP，所著《深入理解C#》（英文版C# in Depth）一書是C#領域少數不可不讀的名著，他現任Google英國公司的一名高階工程師。

在這個話題裡種共有400多個主回貼，以及上千個子回貼中，我覺得很多觀點倒不是有爭議的，而是非常正確的，如果一定要說這些有爭議，那也只能是對哪些沒真正做過開發的人而言的。

下面就和大家一起分享下這些“有爭議的”觀點，希望對你有所幫助！

1. 業餘時間不會為了好玩而程式設計的程式設計師，永遠比不上那些以程式設計為樂的同學。
我認為即使是最聰明、最有才華的人，如果只是將程式設計作為工作，也永遠成不了真正優秀的程式設計師。以程式設計為樂的人會在業餘時也搞些小專案，或者弄弄各種不同的程式語言和程式設計思想。

2. 單元測試無助於編寫優秀程式碼。
編寫單元測試的唯一理由僅僅是確保已經能工作的程式碼不會出問題。先寫測試或者按測試來寫程式碼是無比荒謬的。如果在程式碼之前寫測試，你都不知道邊界情況是什麼。雖然能讓程式碼通過測試，但是在沒有預見到的情況時還是會出問題。而且，好的開發人員會盡量降低內聚性，新增程式碼不可能使已有的出問題。

3. 唯一能放之四海而皆準的最佳實踐，是“用腦子思考”。
太多人喜歡追逐眾多時髦技術，想方設法把各種方法、模式、框架用到不適合的地方。新技術和名人大牛的觀點並等於適用於實際情況。

4. 大多數程式碼中的註釋實際上都是程式碼重複的惡性表現。
我們大部分時間是在維護其他人（或者我們自己）寫的程式碼，而糟糕、錯誤、過時和誤導性的註釋肯定是程式碼中最令人糾結的東西之一。很多人最終會將它們幹掉。應該把精力放在提高程式碼的可讀性、必要時就重構、少用慣用法和奇技淫巧上。另外，許多教材還在宣揚什麼註釋甚至比程式碼還重要，結果導致了大量廢話連篇的註釋。

5. 依賴Google沒什麼錯。
這種言論肯定會讓那些學富五車的飽學之士惱火。但是誰都需要查資料不是？正確答案就是正確答案，管它是來自哪本祕籍或者私相傳授，還是Google出來的呢？重要的是能真正理解，並給出成功的程式設計解決方案，讓客戶和老闆滿意。

6. 程式設計師不是生而平等的。
經理往往認為程式設計師A==程式設計師B，因為他們的年頭差不多。實際上，一個開發者的效能可以是另一個的十倍甚至百倍。

7. 我實在不能理解為什麼Java是最適合大學教學的第一門語言。
首先，我相信第一門程式語言應該重在學習控制流和變數，而不是物件和語法。其次，我認為沒有除錯C/C++記憶體洩漏經驗的人，根本無法完全理解Java的初衷。而且，自然的發展過程應該是從“我怎樣做這事”到“我怎樣找到能做這事的庫”，而不是倒過來。

8. 如果你只會一門語言，無論多麼精通，仍然不是優秀的程式設計師。
有人認為，只要精通了C#、Java或者其他什麼你學會的第一門語言，就足夠了。我不敢苟同。我學習的每一種新語言，都教了不少程式設計新知，能夠反過來用於工作中。任何人只侷限於一種語言，都無法充分發揮自己的潛力。而且缺乏求知慾和探索意願，都不符合優秀程式設計師的特質。

9. 偶爾寫寫垃圾程式碼也無妨。
有時候一些特定任務，快而髒的程式碼能搞定就行了。模式、ORM、SRP（單一職責原則）啥的算了吧。

10. print語句是合法的除錯方式。
我認為用 System.out.println 之類的輸出語句除錯程式碼挺好。這經常比正式的除錯要快，而且可以比較不同執行的輸出結果。但是投入生產環境之前一定要刪除這些語句，或者將它們放入日誌語句中。

11. 你的工作是要把自己摘出來。
你寫的軟體都應該讓其他任何開發人員花一點時間就能理解並接手。軟體應該設計優雅，程式碼清晰和一致，格式乾淨，文件合適，每日構建，有恰當的版本管理。如果你被車撞了、被開了、辭職了，公司應該很快能有人很快替代你。如果不能，那你就太悲劇了。有意思的是，你越這樣做，你對公司的價值越大。

12. getter和setter被極度濫用了。
成千上萬的人都說公共欄位是罪惡的，應該設為私有，提供getter和setter。我覺得其實沒啥不同，除非程式是多執行緒的，或者訪問方法中有業務或者展示邏輯（這可夠怪的）。我並不是贊成用公共欄位，只是反對用訪問方法或者屬性包一下，就號稱封裝、資訊隱藏了。

13. SQL也是程式碼，請等而視之。
SQL和C#, Java或者其他物件、過程語言沒什麼不同，請注意程式碼的格式、可讀性和可維護性。

14. UML圖被高估了。
有些圖當然是有用的，比如Composite模式的類圖。但許多UML圖都毫無價值。

15. 可讀性是程式碼最重要的方面。
比正確性還重要。可讀的程式碼也容易修正，容易優化、修改、理解。而且其他開發者也能從中獲益。

16. XML被大大高估了。
很多隨波逐流跳上XML這黑船的人都沒過腦子。XML用於Web應用不錯，因為它本來就是幹這個的。此外的問題定義、設計思路應該儘量不用XML。

17. 軟體開發只是一份工作而已。
我熱愛軟體開發， 我現在一家創業公司幹，每週公司60小時，而且工資不高，只因為團隊很棒，工作很有趣。但站得高一點來看，這仍然只是一份工作而已。它不如家庭、我的女友、其他朋友、幸福等等重要。要是有足夠的錢，我寧願去玩摩托、遊艇或單板滑雪。許多開發者忘記了寫程式不是最終目的，它只是為我們提供條件，去高高興興地做生命中最重要的事情。

18. 開發人員就應該能夠寫程式碼。

19. 設計模式弊大於利。
軟體設計，尤其是好的軟體設計千變萬化，沒法有意義地用模式去總結，尤其是那些大家記得住的幾個模式，而且這些模式也太抽象了，其實沒幾個人真正記得住太多。所以設計模式其實沒啥用。而另一方面呢，又有太多的人為設計模式的概念迷住，想方設法到處用——結果程式碼中往往除了一些毫無意義的單例和抽象工廠之外，幾乎找不到什麼設計。

20. 程式碼少少益善。
如果使用者看不到你的工作，才是做對了。榮耀在別處。