在StakeOverflow上有這樣一個貼子叫“Confessions of your worst WTF moment”（WTF就是What the fuck的縮寫），挺有意思的，我摘幾個小故事過來，希望大家在笑過之后能從中學(xué)到什么——所有的經(jīng)驗都是從錯誤中來的（我在其中加了一些點評）

我們公司的軟件是給警察局用的，那是一個對用來處理被逮捕的人的系統(tǒng)，此系統(tǒng)還需要收集臉部特征和指紋信息，并且，這個系統(tǒng)還會向FBI的系統(tǒng)提交這些信息。當(dāng)我們在測試這個系統(tǒng)的時候，我們一般都是用我們自己的指紋，當(dāng)然，數(shù)據(jù)庫聯(lián)著的是我們的測試數(shù)據(jù)庫。不過，有一次，在我們測試完后，我們忘了把系統(tǒng)切換回生產(chǎn)庫，于是我們的測試數(shù)據(jù)庫就聯(lián)上了生產(chǎn)環(huán)境，于是我們的指紋信息和照片就散布到了其它系統(tǒng)中……清除我們警察局這邊的還好辦，但是，你需要波士頓警察局警司去法院簽字才能從FBI的數(shù)據(jù)庫中清除我們的信息。

　　點評：測試環(huán)境和生產(chǎn)環(huán)境的數(shù)據(jù)不要混在一起。

有一次，我需要向新系統(tǒng)中導(dǎo)入一堆數(shù)據(jù)，因為數(shù)據(jù)量太大，需要5個小時，只能在夜里來干，在系統(tǒng)需要正式使用前2個小時，數(shù)據(jù)導(dǎo)完了，此時是凌晨4點。隨后，我需要刪除一些數(shù)據(jù)，于是我在SQL命令地上輸入了“DELETE from important_table; where id=4”。是的，我沒有看到哪里還有個分號，天啊。

　　點評：這就是加班工作的惡果。另，在delete之前最好先做一次select。

我把我的管理員口令提交到了一個開源軟件的源碼里。

　　點評：1）版本管理器里的東西是刪不掉的。2）一些用戶和口令要hard code在代碼里，所以，不要混用代碼使用的權(quán)限和管理員的權(quán)限，小心管理程序的運行權(quán)限，為其注冊專門的用戶。

我為一個很大的銀行開發(fā)軟件，在我的代碼里，我為一段理論上根本不可能執(zhí)行到的代碼加了一個報錯信息。有一天，不可思異的事發(fā)生了，這條報錯信息顯示在了該銀行的1800個分行的超過10000個終端上——“如果你看到這個信息，說明整個系統(tǒng)被Fuck了，回家吧，祝你過得愉快！”

　　點評：“假設(shè)是惡魔”，Assume意為Ass – u – me，意為——搞砸你和我。對于一些關(guān)鍵東西，永遠不要做假設(shè)。小心你言語中的——“可能、應(yīng)該、覺得、不應(yīng)該”等詞語，程序可不認這些東西。

我遠程登錄到服務(wù)器上加幾個防火墻規(guī)則。第一件我想干的事是在不允許任何人的任何連接，第二件是，為某個端口打開訪問權(quán)限。不過，我在做完第一件事后就把配置保存了，結(jié)果其生效了……

　　點評：這樣的事經(jīng)常發(fā)生，做遠程網(wǎng)絡(luò)管理的人多少會有那么幾次發(fā)生這樣的錯誤。在你將你的網(wǎng)絡(luò)配置生效前，你得想一想，斷線了你是否還能登得上去。改配置不要太沖動，生效前檢查幾次。

我們的代碼中有一個模塊完美地工作了很多年了，只是代碼太亂了。我說服了我的老板，我可以重寫這個模塊，于是我花了三個星期來重寫這個模塊。今天，我還記得，我的老板站在我的后面看著我，而我在流著斗大的汗珠去fix被我重寫的“超級漂亮”的那個模塊中一個接一個的bug。從那以后，我再也不重寫代碼了，除非有重大的利益。

　　點評：這就所謂的屠宰式編程。這個案例告訴我們兩個道理，1）維護代碼要用最最最保守的方法來進行。2）重構(gòu)代碼前要像一個商人一樣學(xué)會計算利益。當(dāng)然，ThoughtWorks的咨詢師一定會告訴你TDD，結(jié)對，極限等等方法告訴你如果實踐重構(gòu)。但我想告訴你，一個程序在生產(chǎn)環(huán)境里運行好幾個年能沒有問題是一件很不容易的事，那怕其中的代碼再爛，你再看不過去，你都要有一個清醒的頭腦明白這幾點，1）軟件的運行質(zhì)量是遠遠大于代碼質(zhì)量的，2）你的測試案例是玩玩小于生產(chǎn)環(huán)境的，3）軟件的完美的質(zhì)量，是靠長時間的運行、測試和錯誤堆出來的，而不是某種方法論。

　　————————————————

　　相信大家做程序員這一生中也有很多發(fā)生在自己身上的悲催的事兒，歡迎分享。我先分享幾個我親身經(jīng)歷過的事。

　　一個發(fā)生在我的領(lǐng)導(dǎo)身上。

我98年剛參加工作的時候，在某單位網(wǎng)絡(luò)部門，一次，我們整個部門去給下屬單位培訓(xùn)Cisco路由器，結(jié)果我們發(fā)現(xiàn)帶去培訓(xùn)地點的設(shè)備少帶了集線器HUB，設(shè)備連不起來。于是領(lǐng)導(dǎo)很不高興，質(zhì)問我們?yōu)槭裁礇]有帶集線器？那幾個對領(lǐng)導(dǎo)平時就不滿的老員工說辦公室里沒有集線器了，都借給別的部門了。領(lǐng)導(dǎo)想了想，問我：“陳皓，我記得上次我給過你個集線器”，我說，“好像沒有吧，我記不起來了，什么牌的？幾口的？”，領(lǐng)導(dǎo)說：“什么牌子想不起來了，不過我記得那個集線器是一個口的”。“一個口的？！”，我心里嘀咕著，“真敢說啊”。但我不敢接話了。那幾個老員工來勁了——“哪有一個口的HUB啊，一個口的怎么聯(lián)兩臺電腦啊？”，領(lǐng)導(dǎo)說：“用兩個一個口的不就行了”。領(lǐng)導(dǎo)這話一出，全場一片寂靜，無言以對……

　　后來：我們所有的組員都離開了我們的這個領(lǐng)導(dǎo)，我們的這個領(lǐng)導(dǎo)今天還在那里工作。我想告訴大家，很多時候該走的是領(lǐng)導(dǎo)（包括外企，我上一東家正在裁人，不過我覺得該被裁掉的應(yīng)該是那些經(jīng)理）。我們的領(lǐng)導(dǎo)經(jīng)常出這樣或那樣的笑話，這讓我隨時隨地地警醒自己——“不要當(dāng)一個被人笑話的經(jīng)理”，于是，今天我還在努力地學(xué)習(xí)技術(shù)。

　　另一個發(fā)生在我身上。

剛剛接觸Linux的時候，還不是很懂，那時的PC還只有奔3，編譯公司的程序好慢啊，有時候為了調(diào)查一個問題，需要不斷地打log，來來回回地編譯，很不爽。直到有一天，硬盤不夠了，df一下，發(fā)現(xiàn)/dev/shm還有空間。于是，把全部程序copy了過去，發(fā)現(xiàn)編譯起程序超快無比，爽得不行。于是就把工作環(huán)境放在/dev/shm下了，連開發(fā)都放在這里了。這一天，開發(fā)一個功能，改了十來個文件，加班很晚，覺得基本搞定，大喜，回家睡覺。第二天一來，發(fā)現(xiàn)/dev/shm下空了，一個文件都沒有了，問同事，同事不知，同事還安慰我說，上次他的文件也不知道被誰刪了，于是我大怒，告老板！老板也怒，發(fā)郵件到整個公司質(zhì)問大家誰刪了陳皓的程序，無人應(yīng)答。IT部門答，“昨晚唯一的操作就是重啟了linux服務(wù)器，什么也沒干，不過我們天天備份服務(wù)器，可以恢復(fù)”，IT部門問我丟的文件在哪個目錄下？于是，我reply to all –“在/dev/shm下……”，哎，人丟大發(fā)了……

　　后來：我很感謝我以前犯的這個錯，從那天以后，我開始立志學(xué)好Linux，這個錯誤讓我努力，讓我發(fā)奮。所以，我想告訴大家——尤其是剛出道的程序員，你們要多多犯錯，要犯錯那種丟死人的錯，這樣你才會知恥而勇。

　　再來一個發(fā)生在我同事身上的。

01年，我們開發(fā)銀行系統(tǒng)，在AIX上開發(fā)，RICS6000很貴，只能在客戶那里開發(fā)，開發(fā)進度很緊張，慢慢地硬盤就不夠用了，系統(tǒng)中有大量的垃圾文件，于是需要清除一些文件，于是有一個同事寫了一個腳本，可以自動清除的各種不重要的文件，里面有一條命令大致是這個樣子“ rm -rf ${app_log_dir}/*”，意為清除程序運行的日志。為了使用這個腳本，需要在root用戶下運行，一開始還不錯。直到有一天，某人一運行，整個根就沒了。搞得整個團隊只能用一周前的備份重寫已寫好的代碼。后來，才發(fā)現(xiàn)原因是${app_log_dir}變量為空，于是成了“rm -rf /*”……

　　后來：這個事后，我的那個同事，把rm命令改了名，并自己寫了一個rm命令，把刪除的文件先放到一個臨時目錄下。而我也因為這個事情，到今天，每次當(dāng)我在root目錄下使用rm時，敲擊回車的手都是抖的。（另，rm時永遠使用絕對路徑）這里，我想告訴大家——犯錯不可怕，可怕的是不會從中總結(jié)教訓(xùn)，同一個錯犯兩次。

　　歡迎分享發(fā)一在你身上那些悲催的事。

it知識庫：程序員那些悲催的事兒，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。