來源：劉江
知名問答網站StackOverflow之所以成功，合理的規則與嚴格執行是重要的原因，所以刪帖是經常的。不過有時候執行得過嚴了，被刪的問答不時會有驚豔之作。這不，他們的部落格8月29日的文章“20個最受爭議的程式設計觀點”說的就是這樣一個被刪帖。此文一出，立刻在 Reddit/Programming、Hacker News等各大技術新聞站上引起了熱議。
實際上陳皓曾經翻譯介紹過其中的十條，但觀點本身沒有翻譯。
最初的問題“你最受爭議的程式設計觀點是什麼？”（這裡還能看到存檔），由Jon Skeet在2009年1月提出。此人可不是無名小卒，C#社群大名鼎鼎的人物，多年微軟MVP，所著《深入理解C#》（英文版C# in Depth）一書是C#領域少數不可不讀的名著（老趙就說過C#他只推薦兩本，這本和CLR via C#），現在Google英國公司任工程師（還真不知道他在那裡幹什麼）。
那麼，這個問題當時都有哪些熱門答案呢？順序是隨機的。
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圖都毫無價值。
CSDN編者注：記得Robert Martin在《敏捷軟體開發（C#版）》裡講UML時，基本上是講一個圖然後說，好像沒什麼用，我就沒怎麼用過……同一個問題下面還有一個相關的答案：程式碼==設計。認為高階語言程式碼比UML圖和文件更有效。
15、可讀性是程式碼最重要的方面。
比正確性還重要。可讀的程式碼也容易修正，容易優化、修改、理解。而且其他開發者也能從中獲益。
16、XML被大大高估了。
很多隨波逐流跳上XML這黑船的人都沒過腦子。XML用於Web應用不錯，因為它本來就是幹這個的。此外的問題定義、設計思路應該儘量不用XML。
17、軟體開發只是一份工作而已。
我熱愛軟體開發， 我現在一家創業公司幹，每週公司60小時，而且工資不高，只因為團隊很棒，工作很有趣。但站得高一點來看，這仍然只是一份工作而已。它不如家庭、我的女友、其他朋友、幸福等等重要。要是有足夠的錢，我寧願去玩摩托、遊艇或單板滑雪。許多開發者忘記了寫程式不是最終目的，它只是為我們提供條件，去高高興興地做生命中最重要的事情。
CSDN編者注：這條和第1條好像有點對著來嘛。
18、開發人員就應該能夠寫程式碼。
去年做了很多面試，我主要會測人們的思路，如何在白板上實現比較簡單的演算法。我往往從這樣的問題開始：
已知Pi可以用函式4 * (1 – 1/3 + 1/5 – 1/7 + …) 計算，項越多越精確，請寫一個函式，計算小數點後5位的Pi。
這是一個10行C#就能搞定的問題。但許多面試者甚至毫無思路。所以我只好接著問這樣的問題：
已知圓的面積是Pi乘以半徑的平方，寫一個函式計算。
居然有超過半數的人無法用任何語言完成這個函式！唉，開發人員應該能夠寫程式碼，現在連這個都成有爭議的觀點了……
19、設計模式弊大於利。
軟體設計，尤其是好的軟體設計千變萬化，沒法有意義地用模式去總結，尤其是那些大家記得住的幾個模式，而且這些模式也太抽象了，其實沒幾個人真正記得住太多。所以設計模式其實沒啥用。而另一方面呢，又有太多的人為設計模式的概念迷住，想方設法到處用——結果程式碼中往往除了一些毫無意義的單例和抽象工廠之外，幾乎找不到什麼設計。
20、程式碼少少益善。
如果使用者看不到你的工作，才是做對了。榮耀在別處。
其他比較熱門的答案還有：
21. 效能真的很重要。
22. 企業應用很滑稽。需要n年經驗是胡扯。電腦科學學位課程純忽悠。（連結）
23. 單元測試無助於編寫好程式碼，軟體工程大多數所謂的最佳實踐都是為了防範爛程式設計師搞太多破壞。（連結）
24. 每個程式設計師都應該熟悉現代計算機的體系結構。
25. 編寫小方法。
26. PHP真爛！
27. C++是有史以來最差的語言之一。（連結）
28. 大多數職業程式設計師都很爛。
29. 要想成為程式設計師，你得先學會打字。
30. 程式設計之外的各種流程規矩越多，程式碼質量越差。（連結）
資深的遊戲程式設計師James Hague（名博Prog21是也）也看到此文，覺得這些觀點都沒啥太大爭議性。他專門寫了一篇部落格，又提出了他自認為更具爭議性的觀點，其中不少觀點指向他之前發表的其他文章：
31. 電腦科學專業應該只作為輔修學位。
32. 新程式設計師還沒有弄懂分解問題和將解決方法變成程式碼之前，就給他們介紹物件導向是大錯特錯。
33. 複雜的編譯器優化幾乎都沒什麼價值，即使能得到更快的程式碼。它們會大大降低編譯速度而且很可能產生難以處理的bug，使效能問題的處理更加困難。
34. 不能允許沒有十年程式設計經驗的人編寫供他人使用的庫。忽略此條，抱憾終身。
35. 程式碼醜陋與否無關緊要。有沒有格式與程式碼是否工作、可靠沒什麼關係，可以讓自動化工具來整理格式。
36. 純函數語言程式設計沒啥用。但在命令式程式碼裡雜用一些效果不錯。
37. 軟體工程的既定思維反而會阻礙你做出偉大作品。
對這些程式設計觀點你怎麼看？你有什麼值得爭議的驚人之語嗎，歡迎曬出來大家共賞析。