[[358485]]

首先這是程序員問答論壇stackoverflow中“您最有爭議的編程觀點是什么?” 問題的高分問答的集錦，但這個帖子已經(jīng)被刪除了，也就是說死無對證。

1. 業(yè)余時間不以編程為樂的程序員，永遠不會像以編程為樂的程序員一樣優(yōu)秀。

我認(rèn)為即使是最聰明、最有天賦的人也不會成為真正優(yōu)秀的程序員，除非他們把它當(dāng)成比工作更重要的事情。也就是說，他們在業(yè)余時間做一些小項目，或者只是在業(yè)余時間搞很多不同的語言和想法。

作者 rustyshelf

2. 單元測試不會幫助你寫出好的代碼。

有單元測試的唯一原因是為了確保已經(jīng)能用的代碼不會出錯。先寫測試，或者先寫代碼再寫測試都很可笑的。如果你先寫測試再寫代碼，你甚至不知道邊緣情況是什么。你可能會有通過測試的代碼，但在不可預(yù)見的情況下仍然失敗。而且，好的開發(fā)人員會保持較低耦合，這將使新代碼的添加不太可能導(dǎo)致現(xiàn)有的東西出現(xiàn)問題。

作者：Chad Okere

3. 你唯一應(yīng)該一直使用的 “最佳實踐 “就是 “開動自己的腦筋”。

太多的人都趕時髦，試圖把方法、模式、框架等強加到不值得的事情上。僅僅因為某些東西是新的，或者因為某個受人尊敬的人有一個觀點，并不意味著它適合所有的人。

作者：Steven Robbins

4. 大多數(shù)代碼中的注釋其實是一種垃圾代碼的重復(fù)。

我們花了大部分時間來維護別人(或我們自己)寫的代碼，而拙劣的、不正確的、過時的、誤導(dǎo)性的注釋一定是代碼中最令人討厭的人工制品的榜首。我想最終很多人都會把它們忽略掉，尤其是那些花盒怪獸。更好的做法是專注于使代碼可讀，必要時重構(gòu)，并盡量減少習(xí)語和怪癖。另一方面，許多課程教導(dǎo)說注釋幾乎比代碼本身更重要，導(dǎo)致下一行給 invoiceTotal 增加一個注釋的風(fēng)格。

作者：Ed Guiness

5. “上網(wǎng)查查 “未嘗不可!

是的，我知道這觸犯了一些人的利益，他們多年緊張的記憶和/或光榮的一摞編程書籍，開始被一個任何人都可以在幾秒鐘內(nèi)訪問的資源所取代，但你不應(yīng)該對使用它的人持反對態(tài)度。我經(jīng)常聽到google解決問題的答案是批評的結(jié)果，這真的是沒有意義的。

首先，必須承認(rèn)，每個人都需要材料來參考。你不是什么都懂，你也需要查資料。承認(rèn)了這一點，你從哪里得到的資料真的重要嗎?你是在書上查的，還是在谷歌上查的，還是從一只會說話的青蛙那里聽到的，這重要嗎?不，一個正確的答案就是一個正確的答案。重要的是你理解了這些材料，把它作為成功的編程方案的手段，并且客戶/你的雇主對結(jié)果滿意。

作者：PhoenixRedeemer

6. 不是所有的程序員受到合理待遇。

很多時候，管理者認(rèn)為開發(fā)人員A等效于開發(fā)人員B，只是因為他們的經(jīng)驗水平相同等等。實際上，一個開發(fā)人員的業(yè)績可能是另一個開發(fā)人員的10倍甚至100倍。談?wù)撨@個問題在政治上是有風(fēng)險的，但有時我覺得應(yīng)該指出，即使幾個團隊成員看起來技術(shù)相當(dāng)，但情況并不總是如此。我甚至看到過這樣的情況：主要開發(fā)人員 “無可奈何”，而初級開發(fā)人員做了所有的實際工作–雖然我相信他們得到了贊美。

作者：Dmitri Nesteruk

7. 我不明白為什么人們認(rèn)為Java是大學(xué)里最好的 “第一 “編程語言。

其一，我認(rèn)為第一門編程語言應(yīng)該是這樣的，它強調(diào)的是學(xué)習(xí)控制流和變量，而不是對象和語法。其二，我相信沒有在C / C++中調(diào)試內(nèi)存泄漏經(jīng)驗的人不能完全理解Java帶來的東西。另外，自然的進展應(yīng)該是從 “我怎么能做這個 “到 “我怎么能找到能做那個的庫”，而不是相反。

作者 Learning

8. 如果你只懂一門語言，不管你對它有多精通，你都不是一個偉大的程序員。

似乎有一種態(tài)度認(rèn)為，一旦你真的擅長C#或Java或其他任何你開始學(xué)習(xí)的語言，那么這就是你所需要的。我不這樣認(rèn)為，因為我所學(xué)過的每一門語言都教會了我一些關(guān)于編程的新東西，這些知識再反哺工作。我認(rèn)為，任何一個人如果把自己限制在一門語言上，就永遠不會有好的表現(xiàn)。這也向我表明了某種缺乏好奇心和嘗試的意愿，這不一定符合我期望在一個真正優(yōu)秀的程序員身上找到的品質(zhì)。

作者：glenatron

9. 偶爾寫一些垃圾代碼是可以的。

有時候，為了完成一個特定的任務(wù)，只需要一段快速而骯臟的垃圾代碼。模式，ORM，SRP，不管是什么……在控制臺搞一下或簡單寫個Web應(yīng)用程序，寫一些內(nèi)聯(lián)SQL，然后快速地完成需求。

作者：jfar

10. 打印語句是調(diào)試代碼的有效方法。

我相信，通過使用System.out.println(或任何適合你的語言的打印語句)來調(diào)試你的代碼是完全可行的。通常情況下，這可以比調(diào)試更快，而且你可以將打印的輸出與應(yīng)用程序的其他運行進行比較。只要確保在生產(chǎn)時刪除打印語句(或者更好的是，將它們變成日志語句)。

作者：David

11. 你的工作就是讓自己失業(yè)。

當(dāng)你為你的雇主編寫軟件時，你所創(chuàng)建的任何軟件都要以這樣的方式編寫，即它可以被任何開發(fā)人員拾起并以最小的努力理解。它設(shè)計得很好，寫得清晰一致，格式干凈，在需要的地方有文檔，每天按預(yù)期構(gòu)建，檢查到倉庫，并有適當(dāng)?shù)陌姹尽?/p>

如果你被公交車撞了，下崗，被解雇，或者走下神壇，你的雇主應(yīng)該能夠在一瞬間通知你替換你，下一個人可以介入你的角色，拿起你的代碼，頂多一周內(nèi)就可以開始運行。如果他或她做不到這一點，那你就太失敗了。有趣的是，我發(fā)現(xiàn)，有了這個目標(biāo)，我對雇主來說更有價值。我越是努力成為一次性的人，對他們來說就越有價值。

作者：邁克-霍弗

12. Getters和Setters被過度使用。

我見過數(shù)以百萬計的人聲稱公共字段是邪惡的，所以他們將其私有化，并為所有字段提供getter和setter。我相信這與將字段公開幾乎是一樣的，如果你使用線程(但一般情況下不是這樣)或者如果你的訪問者有業(yè)務(wù)/展示邏輯(至少是一些 “奇怪 “的東西)，也許會有一點不同。我并不贊成公共字段，但反對為每個字段建立一個getter/setter(或Property)，然后聲稱這樣做是封裝或信息隱藏……哈哈!我認(rèn)為，這是不對的。

作者：Pablo Fernandez

13. 別拿SQL不當(dāng)代碼。

也就是說，就像你的C#、Java或其他喜歡的對象/程序語言一樣，開發(fā)一種可讀和可維護的格式化風(fēng)格。我討厭看到馬虎的自由格式化的SQL代碼。如果你在頁面上看到兩種樣式的大括號時都會尖叫，那么當(dāng)你看到自由格式化的SQL或模糊或混淆JOIN條件的SQL時，你為什么或為什么不尖叫呢?

作者：MustStayAnonymous

14. UML圖被高度高估了。

當(dāng)然有一些有用的圖，比如復(fù)合模式的類圖，但是很多UML圖完全沒有價值。

當(dāng)然也有一些有用的圖，比如復(fù)合模式的類圖，但是很多UML圖完全沒有價值。

作者：Ludwig Wensauer

15. 可讀性是最重要的。

可讀性甚至比正確性更重要。如果它是可讀的，它就很容易修復(fù)。也容易優(yōu)化，容易改變，容易理解。而且希望其他開發(fā)者也能從中學(xué)到一些東西。

作者：Craig P. Motlin

16. XML被高估了。

我認(rèn)為有太多的人從未經(jīng)過思考，就跳上了XML的浪潮……XML用于網(wǎng)絡(luò)的東西是很好的，因為它是為它設(shè)計的。否則，我認(rèn)為一些問題定義和設(shè)計思想應(yīng)該優(yōu)先于任何使用它的決定。

作者：Over Rated

17. 軟件開發(fā)也只是一份工作。

我很喜歡軟件開發(fā)。在過去的幾年里，我寫了一個關(guān)于這個主題的系列博客。我在這里花了足夠多的時間，有超過5000個信譽點。我在一家初創(chuàng)公司工作，每周工作時間通常為60小時，收入比我作為一個承包商要少得多，因為團隊很棒，工作也很有趣。

但本質(zhì)而言，這只是一份工作。它的重要性排在很多事情之下，比如家庭、我的女朋友、朋友、幸福等，如果有無限的現(xiàn)金供應(yīng)，我肯定選擇做的其他事情之下，比如騎摩托車、帆船游艇或者滑雪板。我覺得有時候很多開發(fā)者忘記了，開發(fā)只是讓我們擁有生活中更重要的東西(通過做我們喜歡的事情來擁有)，而不是作為最終目標(biāo)本身。

作者：Greg Beech

18. 如果你是一個開發(fā)人員，你應(yīng)該會寫代碼。

(這不是廢話嗎，看完我不太相信)

去年我做了不少面試，我面試的部分應(yīng)該是測試大家的思維方式，以及如何在白板上實現(xiàn)簡單到中等的算法。我一開始的問題是這樣的。

考慮到Pi可以用函數(shù)4*(1 – 1/3 + 1/5 – 1/7 +… )來估計，更多的項會帶來更高的精度，請寫一個函數(shù)，計算Pi的精度達到小數(shù)點后5位。

這是一個應(yīng)該讓你思考的問題，但對于一個經(jīng)驗豐富的開發(fā)人員來說，應(yīng)該不是遙不可及的問題(用大約10行C#語言就可以回答)。然而，我們的許多(據(jù)說是經(jīng)過機構(gòu)預(yù)選的)候選人甚至無法開始回答這個問題，甚至無法解釋他們?nèi)绾稳セ卮疬@個問題。所以過了一段時間后，我開始問一些比較簡單的問題，比如。

假設(shè)圓的面積是Pi乘以半徑的平方，寫一個函數(shù)來計算圓的面積。

令人驚訝的是，超過一半的考生不會用任何語言寫這個函數(shù)(我可以讀懂大多數(shù)流行的語言，所以我讓他們使用任何他們選擇的語言，包括偽代碼)

我們有 “C#開發(fā)人員 “不能用C#寫這個函數(shù)。我對此感到很驚訝。我一直認(rèn)為，開發(fā)人員應(yīng)該能夠?qū)懘a。現(xiàn)在看來，這是個有爭議的觀點。當(dāng)然，在面試候選人中也是如此

作者：Greg Beech

19. 設(shè)計模式對好設(shè)計的傷害大于幫助。

軟件設(shè)計，尤其是好的軟件設(shè)計太多變了，無法用模式來有意義地捕捉，尤其是人們能真正記住的模式數(shù)量很少–而且這些模式太抽象了，人們真正能記住的不只是少數(shù)幾個。所以它們沒有什么幫助。而另一方面，太多人迷戀這個概念，并試圖將模式應(yīng)用到各個地方–通常，在所產(chǎn)生的代碼中，你無法在所有(完全沒有意義的)Singletons和Abstract Factories之間找到實際的設(shè)計。

作者：Michael Borgwardt

20. 代碼越少越好

如果用戶說 “就這(么點)?”，沒有體現(xiàn)你的工作量，那就是做對了。相信我，你要把這當(dāng)成對你的最高贊譽。

作者：Jas Panesar