知名問答網站StackOverflow之因此成功，合理的規則與嚴格執行是重要的緣由，因此刪帖是常常的。不過有時候執行得過嚴了，被刪的問答不時會有驚豔之做。這不，他們的博客8月29日的文章「20個最受爭議的編程觀點」說的就是這樣一個被刪帖。此文一出，馬上在Reddit、Hacker News等各大技術新聞站上引發了熱議。面試
最初的問題「你最受爭議的編程觀點是什麼？」，由Jon Skeet在2009年1月提出。此人可不是無名小卒，C#社區大名鼎鼎的人物，多年微軟MVP，所著《深刻理解C#》（英文版C# in Depth）一書是C#領域少數不可不讀的名著（老趙就說過C#他只推薦兩本，這本和CLR via C#），如今Google英國公司任工程師（還真不知道他在那裏幹什麼）。算法
那麼，這個問題當時都有哪些熱門答案呢？順序是隨機的。 數據庫
- 業餘時間不會爲了好玩而編程的程序員，永遠比不上那些以編程爲樂的同窗。
我認爲即便是最聰明、最有才華的人，若是隻是將編程做爲工做，也永遠成不了真正優秀的程序員。以編程爲樂的人會在業餘時也搞些小項目，或者弄弄各類不一樣的編程語言和編程思想。編程
- 單元測試無助於編寫優秀代碼。
編寫單元測試的惟一理由僅僅是確保已經能工做的代碼不會出問題。先寫測試或者按測試來寫代碼是無比荒謬的。若是在代碼以前寫測試，你都不知道邊界狀況是什麼。雖然能讓代碼經過測試，可是在沒有預見到的狀況時仍是會出問題。並且，好的開發人員會盡可能下降內聚性，新增代碼不可能使已有的出問題。設計模式
- 惟一能放之四海而皆準的最佳實踐，是「用腦子思考」。
太多人喜歡追逐衆多時髦技術，千方百計把各類方法、模式、框架用到不適合的地方。新技術和名人大牛的觀點並等於適用於實際狀況。服務器
- 大多數代碼中的註釋實際上都是代碼重複的惡性表現。
咱們大部分時間是在維護其餘人（或者咱們本身）寫的代碼，而糟糕、錯誤、過期和誤導性的註釋確定是代碼中最使人糾結的東西之一。不少人最終會將它們幹掉。應該把精力放在提升代碼的可讀性、必要時就重構、少用慣用法和奇技淫巧上。另外，許多教材還在宣揚什麼註釋甚至比代碼還重要，結果致使了大量廢話連篇的註釋。多線程
- 依賴Google沒什麼錯。
這種言論確定會讓那些學富五車的飽學之士惱火。可是誰都須要查資料不是？正確答案就是正確答案，管它是來自哪本祕籍或者私相傳授，仍是Google出來的呢？重要的是能真正理解，並給出成功的編程解決方案，讓客戶和老闆滿意。框架
- 程序員不是生而平等的。
經理每每認爲程序員A==程序員B，由於他們的年頭差很少。實際上，一個開發者的效能能夠是另外一個的十倍甚至百倍。編程語言
- 我實在不能理解爲何Java是最適合大學教學的第一門語言。
首先，我相信第一門編程語言應該重在學習控制流和變量，而不是對象和語法。其次，我認爲沒有調試C/C++內存泄漏經驗的人，根本沒法徹底理解Java的初衷。並且，天然的發展過程應該是從「我怎樣作這事」到「我怎樣找到能作這事的庫」，而不是倒過來。
- 若是你只會一門語言，不管多麼精通，仍然不是優秀的程序員。
有人認爲，只要精通了C#、Java或者其餘什麼你學會的第一門語言，就足夠了。我不敢苟同。我學習的每一種新語言，都教了很多編程新知，可以反過來用於工做中。任何人只侷限於一種語言，都沒法充分發揮本身的潛力。並且缺少求知慾和探索意願，都不符合優秀程序員的特質。
- 偶爾寫寫垃圾代碼也無妨。
有時候一些特定任務，快而髒的代碼能搞定就好了。模式、ORM、SRP（單一職責原則）啥的算了吧。
- print語句是有效的調試方式。
我認爲用 System.out.println 之類的輸出語句調試代碼挺好。這常常比正式的調試要快，並且能夠比較不一樣運行的輸出結果。可是投入生產環境以前必定要刪除這些語句，或者將它們放入日誌語句中。
- 你的工做是要把本身摘出來。
你寫的軟件都應該讓其餘任何開發人員花一點時間就能理解並接手。軟件應該設計優雅，代碼清晰和一致，格式乾淨，文檔合適，每日構建，有恰當的版本管理。若是你被車撞了、被開了、辭職了，公司應該很快能有人很快替代你。若是不能，那你就太悲劇了。有意思的是，你越這樣作，你對公司的價值越大。
原帖下面有人評論：你若是沒法被替代，也就沒法升職啦。
- getter和setter被極度濫用了。
成千上萬的人都說公共字段是罪惡的，應該設爲私有，提供getter和setter。我以爲其實沒啥不一樣，除非程序是多線程的，或者訪問方法中有業務或者展現邏輯（這可夠怪的）。我並非同意用公共字段，只是反對用訪問方法或者屬性包一下，就號稱封裝、信息隱藏了。
- SQL也是代碼，請等而視之。
SQL和C#, Java或者其餘對象、過程語言沒什麼不一樣，請注意代碼的格式、可讀性和可維護性。
- UML圖被高估了。
有些圖固然是有用的，好比Composite模式的類圖。但許多UML圖都毫無價值。
CSDN編者注：記得Robert Martin在《敏捷軟件開發（C#版）》裏講UML時，基本上是講一個圖而後說，好像沒什麼用，我就沒怎麼用過……同一個問題下面還有一個相關的答案：代碼==設計。認爲高級語言代碼比UML圖和文檔更有效。
- 可讀性是代碼最重要的方面。
比正確性還重要。可讀的代碼也容易修正，容易優化、修改、理解。並且其餘開發者也能從中獲益。
- XML被大大高估了。
不少隨波逐流跳上XML這黑船的人都沒過腦子。XML用於Web應用不錯，由於它原本就是幹這個的。此外的問題定義、設計思路應該儘可能不用XML。
- 軟件開發只是一份工做而已。
我熱愛軟件開發， 我如今一家創業公司幹，每週公司60小時，並且工資不高，只由於團隊很棒，工做頗有趣。但站得高一點來看，這仍然只是一份工做而已。它不如家庭、個人女朋友、其餘朋友、幸福等等重要。要是有足夠的錢，我寧願去玩摩托、遊艇或單板滑雪。許多開發者忘記了寫程序不是最終目的，它只是爲咱們提供條件，去高高興興地作生命中最重要的事情。
CSDN編者注：這條和第1條好像有點對着來嘛。
- 開發人員就應該可以寫代碼。
去年作了不少面試，我主要會測人們的思路，如何在白板上實現比較簡單的算法。我每每從這樣的問題開始：
已知Pi能夠用函數4 * (1 – 1/3 + 1/5 – 1/7 + …) 計算，項越多越精確，請寫一個函數，計算小數點後5位的Pi。
這是一個10行C#就能搞定的問題。但許多面試者甚至毫無思路。因此我只好接着問這樣的問題：
已知圓的面積是Pi乘以半徑的平方，寫一個函數計算。
竟然有超過半數的人沒法用任何語言完成這個函數！唉，開發人員應該可以寫代碼，如今連這個都成有爭議的觀點了……
- 設計模式弊大於利。
軟件設計，尤爲是好的軟件設計變幻無窮，無法有意義地用模式去總結，尤爲是那些你們記得住的幾個模式，並且這些模式也太抽象了，其實沒幾我的真正記得住太多。因此設計模式其實沒啥用。而另外一方面呢，又有太多的人爲設計模式的概念迷住，千方百計處處用——結果代碼中每每除了一些毫無心義的單例和抽象工廠以外，幾乎找不到什麼設計。
- 代碼少少益善。
若是用戶看不到你的工做，纔是作對了。榮耀在別處。
- 性能真的很重要。
- 企業應用很滑稽。須要n年經驗是胡扯。計算機科學學位課程純忽悠。
- 單元測試無助於編寫好代碼，軟件工程大多數所謂的最佳實踐都是爲了防範爛程序員搞太多破壞。
- 每一個程序員都應該熟悉現代計算機的體系結構。
- 編寫小方法。
- PHP真爛！
- C++是有史以來最差的語言之一。
- 大多數職業程序員都很爛。
- 要想成爲程序員，你得先學會打字。
- 編程以外的各類流程規矩越多，代碼質量越差。
資深的遊戲程序員James Hague（名博Prog21是也）也看到此文，以爲這些觀點都沒啥太大爭議性。他專門寫了一篇博客，又提出了他自認爲更具爭議性的觀點，其中很多觀點指向他以前發表的其餘文章：
- 計算機科學專業應該只做爲輔修學位。
- 新程序員尚未弄懂分解問題和將解決方法變成代碼以前，就給他們介紹面向對象是大錯特錯。
- 複雜的編譯器優化幾乎都沒什麼價值，即便能獲得更快的代碼。它們會大大下降編譯速度並且極可能產生難以處理的bug，使性能問題的處理更加困難。
- 不能容許沒有十年編程經驗的人編寫供他人使用的庫。忽略此條，抱憾終身。
- 代碼醜陋與否可有可無。有沒有格式與代碼是否工做、可靠沒什麼關係，可讓自動化工具來整理格式。
- 純函數式編程沒啥用。但在命令式代碼裏雜用一些效果不錯。
- 軟件工程的既定思惟反而會阻礙你作出偉大做品。