那些爭議最大的編程觀點
作者：劉江@CSDN
知名問答網站 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. 軟件工程的既定思維反而會阻礙你做出偉大作品。
對這些編程觀點你怎么看？你有什么值得爭議的驚人之語嗎，歡迎曬出來大家共賞析。