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

[[208474]]

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

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

菜鳥錯誤1：把Make或Shell當成構(gòu)建工具

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

我曾經(jīng)在一個大型網(wǎng)絡(luò)設(shè)備公司工作過，并且通過把它的構(gòu)建轉(zhuǎn)換到Ant(一個Java構(gòu)建工具)，使構(gòu)建進程從3小時縮短到了20秒。

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

菜鳥錯誤2：把IDE用作構(gòu)建工具

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

菜鳥錯誤3：終止AWS實例

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

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

菜鳥錯誤4：測試你在乎的所有內(nèi)容

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

菜鳥錯誤5：追求絕對的數(shù)據(jù)完整性

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

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

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

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

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

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

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

菜鳥錯誤8： I<3繼承

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

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

菜鳥錯誤9： I <3函數(shù)式

你剛剛學到了所有關(guān)于函數(shù)編程的知識。你認為面向?qū)ο缶幊淌莻€大錯誤，所有的東西都應該是無狀態(tài)的和功能性的。那我只能說你很棒棒哦!

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

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

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

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

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

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

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

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

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

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

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

菜鳥錯誤14：row locks的使用

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

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

菜鳥錯誤15：序列的使用

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

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

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