那些爭議最大的編程觀點

　　摘要：那些看似驚人但卻值得回味的編程觀點……

　　知名問答網站StackOverflow之所以成功，合理的規則與嚴格執行是重要的原因，所以刪帖是經常的。不過有時候執行得過嚴了，被刪的問答不時會有驚艷之作。這不，他們的博客8月29日的文章“20個最受爭議的編程觀點”說的就是這樣一個被刪帖。此文一出，立刻在Reddit、Hacker News等各大技術新聞站上引起了熱議。

　　實際上2010年酷殼曾經有文章介紹過其中的十條，但觀點本身沒有翻譯。

　　最初的問題“你最受爭議的編程觀點是什么?”(這里還能看到存檔)，由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圖和文檔更有效。

　　可讀性是代碼最重要的方面。

　　比正確性還重要?？勺x的代碼也容易修正，容易優化、修改、理解。而且其他開發者也能從中獲益。

　　XML被大大高估了。

　　很多隨波逐流跳上XML這黑船的人都沒過腦子。XML用于Web應用不錯，因為它本來就是干這個的。此外的問題定義、設計思路應該盡量不用XML。

　　軟件開發只是一份工作而已。

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

原文轉自：http://www.anti-gravitydesign.com