知名問答**stackoverflow之所以成功，合理的規則與嚴格執行是重要的原因，所以刪帖是經常的。不過有時候執行得過嚴了，被刪的問答不時會有驚豔之作。這不，他們的部落格8月29日的文章「20個最受爭議的程式設計觀點」說的就是這樣乙個被刪帖。此文一出，立刻在reddit、hacker news等各大技術新聞站上引起了熱議。
實際上2023年酷殼曾經有文章介紹過其中的十條，但觀點本身沒有翻譯。
最初的問題「你最受爭議的程式設計觀點是什麼？」（這裡還能看到存檔），由jon skeet在2023年1月提出。此人可不是無名小卒，c#社群大名鼎鼎的人物，多年微軟mvp，所著《深入理解c#》（英文版c# in depth）一書是c#領域少數不可不讀的名著（老趙就說過c#他只推薦兩本，這本和clr via c#），現在google英國公司任工程師（還真不知道他在那裡幹什麼）。
那麼，這個問題當時都有哪些熱門答案呢？順序是隨機的。
我認為即使是最聰明、最有才華的人，如果只是將程式設計作為工作，也永遠成不了真正優秀的程式設計師。以程式設計為樂的人會在業餘時也搞些小專案，或者弄弄各種不同的程式語言和程式設計思想。
編寫單元測試的唯一理由僅僅是確保已經能工作的**不會出問題。先寫測試或者按測試來寫**是無比荒謬的。如果在**之前寫測試，你都不知道邊界情況是什麼。雖然能讓**通過測試，但是在沒有預見到的情況時還是會出問題。而且，好的開發人員會盡量降低內聚性，新增**不可能使已有的出問題。
太多人喜歡追逐眾多時髦技術，想方設法把各種方法、模式、框架用到不適合的地方。新技術和名人大牛的觀點並等於適用於實際情況。
我們大部分時間是在維護其他人（或者我們自己）寫的**，而糟糕、錯誤、過時和誤導性的注釋肯定是**中最令人糾結的東西之一。很多人最終會將它們乾掉。應該把精力放在提高**的可讀性、必要時就重構、少用慣用法和奇技淫巧上。另外，許多教材還在宣揚什麼注釋甚至比**還重要，結果導致了大量廢話連篇的注釋。
這種言論肯定會讓那些學富五車的飽學之士惱火。但是誰都需要查資料不是？正確答案就是正確答案，管它是來自哪本秘籍或者私相傳授，還是google出來的呢？重要的是能真正理解，並給出成功的程式設計解決方案，讓客戶和老闆滿意。
經理往往認為程式設計師a==程式設計師b，因為他們的年頭差不多。實際上，乙個開發者的效能可以是另乙個的十倍甚至百倍。
首先，我相信第一門程式語言應該重在學習控制流和變數，而不是物件和語法。其次，我認為沒有除錯c/c++記憶體洩漏經驗的人，根本無法完全理解j**a的初衷。而且，自然的發展過程應該是從「我怎樣做這事」到「我怎樣找到能做這事的庫」，而不是倒過來。
有人認為，只要精通了c#、j**a或者其他什麼你學會的第一門語言，就足夠了。我不敢苟同。我學習的每一種新語言，都教了不少程式設計新知，能夠反過來用於工作中。任何人只侷限於一種語言，都無法充分發揮自己的潛力。而且缺乏求知慾和探索意願，都不符合優秀程式設計師的特質。
有時候一些特定任務，快而髒的**能搞定就行了。模式、orm、srp（單一職責原則）啥的算了吧。
我認為用 system.out.println 之類的輸出語句除錯**挺好。這經常比正式的除錯要快，而且可以比較不同執行的輸出結果。但是投入生產環境之前一定要刪除這些語句，或者將它們放入日誌語句中。
你寫的軟體都應該讓其他任何開發人員花一點時間就能理解並接手。軟體應該設計優雅，**清晰和一致，格式乾淨，文件合適，每日構建，有恰當的版本管理。如果你被車撞了、被開了、辭職了，公司應該很快能有人很快替代你。如果不能，那你就太悲劇了。有意思的是，你越這樣做，你對公司的價值越大。
成千上萬的人都說公共欄位是罪惡的，應該設為私有，提供getter和setter。我覺得其實沒啥不同，除非程式是多執行緒的，或者訪問方法中有業務或者展示邏輯（這可夠怪的）。我並不是贊成用公共字段，只是反對用訪問方法或者屬性包一下，就號稱封裝、資訊隱藏了。
sql和c#, j**a或者其他物件、過程語言沒什麼不同，請注意**的格式、可讀性和可維護性。
有些圖當然是有用的，比如composite模式的類圖。但許多uml圖都毫無價值。
csdn編者注：記得robert martin在《敏捷軟體開發（c#版）》裡講uml時，基本上是講乙個圖然後說，好像沒什麼用，我就沒怎麼用過……同乙個問題下面還有乙個相關的答案：**==設計。認為高階語言**比uml圖和文件更有效。
比正確性還重要。可讀的**也容易修正，容易優化、修改、理解。而且其他開發者也能從中獲益。
很多隨波逐流跳上xml這黑船的人都沒過腦子。xml用於web應用不錯，因為它本來就是幹這個的。此外的問題定義、設計思路應該盡量不用xml。
我熱愛軟體開發， 我現在一家創業公司幹，每週公司60小時，而且工資不高，只因為團隊很棒，工作很有趣。但站得高一點來看，這仍然只是乙份工作而已。它不如家庭、我的女友、其他朋友、幸福等等重要。要是有足夠的錢，我寧願去玩摩托、遊艇或單板滑雪。許多開發者忘記了寫程式不是最終目的，它只是為我們提供條件，去高高興興地做生命中最重要的事情。
csdn編者注：這條和第1條好像有點對著來嘛。
去年做了很多面試，我主要會測人們的思路，如何在白板上實現比較簡單的演算法。我往往從這樣的問題開始：
已知pi可以用函式4 * (1 – 1/3 + 1/5 – 1/7 + …) 計算，項越多越精確，請寫乙個函式，計算小數點後5位的pi。這是乙個10行c#就能搞定的問題。但許多面試者甚至毫無思路。所以我只好接著問這樣的問題：
已知圓的面積是pi乘以半徑的平方，寫乙個函式計算。居然有超過半數的人無法用任何語言完成這個函式！唉，開發人員應該能夠寫**，現在連這個都成有爭議的觀點了……
軟體設計，尤其是好的軟體設計千變萬化，沒法有意義地用模式去總結，尤其是那些大家記得住的幾個模式，而且這些模式也太抽象了，其實沒幾個人真正記得住太多。所以設計模式其實沒啥用。而另一方面呢，又有太多的人為設計模式的概念迷住，想方設法到處用——結果**中往往除了一些毫無意義的單例和抽象工廠之外，幾乎找不到什麼設計。
如果使用者看不到你的工作，才是做對了。榮耀在別處。
其他比較熱門的答案還有：
21. 效能真的很重要。
22. 企業應用很滑稽。需要n年經驗是胡扯。電腦科學學位課程純忽悠。
23.單元測試無助於編寫好**，軟體工程大多數所謂的最佳實踐都是為了防範爛程式設計師搞太多破壞。
24. 每個程式設計師都應該熟悉現代計算機的體系結構。
25. 編寫小方法。
26. php真爛！
27. c++是有史以來最差的語言之一。
28. 大多數職業程式設計師都很爛。
29. 要想成為程式設計師，你得先學會打字。
30. 程式設計之外的各種流程規矩越多，**質量越差。
資深的遊戲程式設計師james hague（名博prog21是也）也看到此文，覺得這些觀點都沒啥太大爭議性。他專門寫了一篇部落格，又提出了他自認為更具爭議性的觀點，其中不少觀點指向他之前發表的其他文章：
31. 電腦科學專業應該只作為輔修學位。
32. 新程式設計師還沒有弄懂分解問題和將解決方法變成**之前，就給他們介紹物件導向是大錯特錯。
33. 複雜的編譯器優化幾乎都沒什麼價值，即使能得到更快的**。它們會大大降低編譯速度而且很可能產生難以處理的bug，使效能問題的處理更加困難。
34.不能允許沒有十年程式設計經驗的人編寫供他人使用的庫。忽略此條，抱憾終身。
35. **醜陋與否無關緊要。有沒有格式與**是否工作、可靠沒什麼關係，可以讓自動化工具來整理格式。
36. 純函式式程式設計沒啥用。但在命令式**裡雜用一些效果不錯。
37. 軟體工程的既定思維反而會阻礙你做出偉大作品。
觀點 程式設計巨星的唯一秘訣
別以為是那些軟體開發定律，別以為是開發出那些特殊用途的軟體，別以為是軟體設計技術本身。只有一條真理決定了乙個軟體程式設計師的成功還是失敗。由於堅持這個真理，乙個資深的程式設計師能在一天的時間裡學會一門新的程式語言，而由於不堅持這條真理，乙個初級的程式設計師用十年時間也只能掙到乙份餬口的錢 永遠是來實...
觀點 成為程式設計巨星的唯一秘訣
the singular secret of the rockstar programmer程式設計巨星的唯一秘訣 內容如下 別以為是那些軟體開發定律，別以為是開發出那些特殊用途的軟體，別以為是軟體設計技術本身。只有一條真理決定了乙個軟體程式設計師的成功還是失敗。由於堅持這個真理，乙個資深的程式設計...
觀點 成為程式設計巨星的唯一秘訣
the singular secret of the rockstar programmer程式設計巨星的唯一秘訣 內容如下 別以為是那些軟體開發定律，別以為是開發出那些特殊用途的軟體，別以為是軟體設計技術本身。只有一條真理決定了乙個軟體程式設計師的成功還是失敗。由於堅持這個真理，乙個資深的程式設計...