在我還20出頭不懂事的時候就我就在犯這些錯誤，我全都遇到過。但是大多數錯誤我還是一犯再犯。

[[208474]]

編碼的人還在編碼，而菜鳥一直都在犯菜。有時候，甚至經驗豐富的老鳥也會犯一些菜鳥犯的錯誤。但是大多數時候犯的是同一個錯誤。

這些錯誤基本上是屬于戰略上的。你應該先用版本控制管理好你的代碼，但是即使你管理好了你的代碼你還是有可能犯這些戰略上的錯誤，然后就像一個孫子一樣受罪。

菜鳥錯誤1：把Make或Shell當成構建工具

如果你不是使用C或者C++語言，Make就不是那么適用了。Make總是為每個文件重新加載一個編譯器進程。大多數現代語言并不是設計成為每個文件加載單獨的進程，而且你要是想在Java這樣的語言中使用Make解決dependency的問題幾乎是不可能的。

我曾經在一個大型網絡設備公司工作過，并且通過把它的構建轉換到Ant(一個Java構建工具)，使構建進程從3小時縮短到了20秒。

以一個shell腳本來結尾也是一步錯棋。最近我為一個實驗室寫了一個shell框架，因為我不想只是為了一個小實驗室，但卻要所有人都要去下一整個Java工具集，我原以為是一步好棋，但是其實我真是干了件蠢事兒(一如既往)，因為它所依賴的這個軟件的下一個版本打破了一切(一如既往)。如果我吸收了它并提供了一個現代化的構建工具，它應該是能夠更新dependency的。

菜鳥錯誤2：把IDE用作構建工具

大多數的IDE具有一些神奇的構建/部署功能。這在初期可能是件好事，當然僅僅用來測試你自己的代碼是非常不錯的。但是最終會產生依賴項，而且其他人也會參與編寫你的代碼。然后你就會搞不清它為什么是在這臺設備上編寫而不是另一臺。你需要一個IDE之外的可重復構建的工具，它應該要可以在連續集成工具上運行。

菜鳥錯誤3：終止AWS實例

“Terminate”在AWS中意味著“delete everything”——而不是其他大多數工具中的“終止進程”的意思。

我參與的***個亞馬遜網絡服務項目中，有一個開發者推測到一個可以閱讀屬性的工具應該是可以安全運行的。很不幸的是，如果你不小心閱讀了terminate屬性，它就會馬上終止實例。他在所有一切上都運行了，然后終止了100多個實例。AWS大大減少了犯這類錯誤的幾率，但是實際上“terminate(終止)”確切地說應該被稱為“destroy permanently(***地毀滅)”因為開發者terminate(終止)進程時是知道它們是可被以重啟的。但是假如你終止了一個AWS實例，你就永遠失去了它們。

菜鳥錯誤4：測試你在乎的所有內容

上述的開發者還非常容易犯一個菜鳥問題：他把所有我們在乎的東西都測試一遍。正確的做法是他應該創建一個單獨的實例，在這個實例上進行測試。即使你認為你所做的是沒有害處的，你還是應該在安全的環境測試你的假設。

菜鳥錯誤5：追求絕對的數據完整性

我看到不止一位開發者使用READ_SERIALIZED 以及table locks，因為他們極度追求數據完整性。當然還有很多其他的生產鎖強迫癥。其實它們都屬于糟糕的模式設計以及對數據、并發和風險的不現實理解。

菜鳥錯誤6：把你的代碼放進HTML或把HTML放進你的代碼

不論是ASP，JSP，PHP，CGI，或者是直接碼，總是有辦法把代碼塞到HTML里面，而且幾乎總是有辦法寫一些類似out.println(“This is a terrible idea”);.這樣的東西，我曾經有段時間是這么干的——差不多是1995年吧……

然而現在有更多現代的排列。我曾看到看有些人用JavaScript做一些非常惡心的事情都挺似曾相識的。我們當然可以找到很多更好的辦法，例如：一個標簽庫 ，一個事件處理器，啥都行，就是HTML 代碼不行!

菜鳥錯誤7： 使用全能列表

我承認在我不確定數據是如何形成時，我會在原型代碼中做這件事，但一旦我知道，我就很快放棄這種做法。一般使用高級語言的人都會犯“這”樣的錯誤。“這”樣的錯誤是什么呢?基本上就是，他們不用地圖, 關系樹, 或者set，而是把所有東西都列在一張表上，然后所有東西都由你自己整理。更糟糕的是，你選擇一個數組返回列表，并繼續插入中心附近的某個地方。

這種代碼的麻煩在于, 它往往會導致生產。不過, 我想在某些時候, 在操作系統中加載測試垃圾回收器或內存管理是很好的!!!

菜鳥錯誤8： I<3繼承

哇哇哇!你上了一節關于decomposition的課之后，你決定你的***步是把一切組織成***的階級等級。你忘記儲存東西或者使你的項目正常運作——不，你只是想讓大家來了解你的大腦是如何運作的，并牢記一組丑陋的并行類結構。我的天哪!你還是快點去DMTF(Desktop Management Task Force 桌面管理任務組)工作吧!

換句話說，你可以用你屎一樣的標準來讓大家頭痛。但是我勸你***不要這么做!

菜鳥錯誤9： I <3函數式

你剛剛學到了所有關于函數編程的知識。你認為面向對象編程是個大錯誤，所有的東西都應該是無狀態的和功能性的。那我只能說你很棒棒哦!

除非我需要在代碼中添加更多的東西，否則如果我必須解開每一個函數調用來添加它，那么你就失敗了。你失敗得很慘哦。

菜鳥錯誤10： I<3 全球性

寫代碼很難，思考很難，決定某件事的邊界很難。但是你選擇不去掙扎，而是直接選擇那些***眾的邊界。你浪費了內存，你的代碼不能并行, 有線程沖突。但是到時你可別想置身事外哦~

菜鳥錯誤11：使用巨型對象

有一次, 當我和一個新來的實習生一起工作時。我告訴他工作可能會往幾個方向走。其中之一是它們可能會向會話拋出一個巨型對象，然后想為什么“群集不起作用”以及為什么他們的內存不夠了。

果然，我們發現一個帶有數以百計的狀態變量和方法的類文件來置換它們。當然，它們正在把它推送到會話中。這些東西大部分都不需要在會話中進行，基本上是為了形成一個由手工編寫的二級數據庫緩存。這對內存是一個巨大的浪費，并且復制它不僅浪費內存還會造成高成本的不必要的會話復制。

菜鳥錯誤12：死于1000個對象

就像你能擁有的太少，你可以擁有太多。死于1000個對象傾向于菜鳥錯誤8:i<3繼承，但是我也親眼見過在沒繼承的時候出現類似情況。如果你所有的類文件代碼都不到100行，但是你卻有成百上千個這樣的文件，這樣也是錯誤的……

菜鳥錯誤13：我可以合并線程嗎?

大多數應用程序代碼都可以用單線程的世界視圖編寫。但是當你開始寫應用的服務器、數據庫或者其他底層代碼時就不能這么干了，大多數商務軟件都可以用類似的底層代碼來編寫——所以你不用寫這些直接轉到多線程就好了。

所以***別寫了。尤其是現在，不寫線程代碼、分發和利用線程變得越來越容易?？纯碨park是如何工作的吧：你不必把混亂的線程都編織到一起。

菜鳥錯誤14：row locks的使用

這對SQL服務器還有DB2用戶來說確實是個大問題。默認數據庫設置用于大多數平臺上的行鎖(DB2在其他平臺上進行頁面鎖定，這肯定更糟糕了)。Oracle的默認設置就沒那么傻了。網上曾經對行鎖和快照隔離進行過爭論。從理論上來說行鎖效率更高—但是你有多一條帶有爭議性的線程都不行(也就是：大多數軟件的現狀)。

更不用說大多數開發者根本不知道”snapshot isolation”的實際意義，也不知道如何開啟它。所以工作就常常是在負載過輕的狀態運轉著，因為它們用的是row locks b。好好搞清楚snapshot isolation的意義和使用方法吧。千萬別用row locks。

菜鳥錯誤15：序列的使用

來，跟我念：我將不會為特殊鍵使用數據庫序列，除非我真的需要序列化的值(也就是在極少數的情況下。)那就是鎖定和遠程處理在同一個包的時候，這就非常令人痛苦了!

你可以使用一個安全的隨機生成器支撐的128位的UUID，而不是用單線程處理數據庫序列生成器的一切。如果你怕被復制的話，要么你數學很差，要么你并不像重視你的生活那樣重視數據。即使在你生成了萬億個ID之后，你還是有更大的可能性被流星擊中你的大頭哦~

希望你能尊重你自己，你的職業，還有在你之后的維護人員。所以千萬別干傻事兒，但即使你可能是經驗豐富的開發者，有時也還是會犯這些低級錯誤的。