在stakeoverflow上有這樣乙個貼子叫「confessions of your worst wtf moment 」（wtf就是what the ****的縮寫），挺有意思的，我摘幾個小故事過來，希望大家在笑過之後能從中學到什麼——所有的經驗都是從錯誤中來的（我在其中加了一些點評）
我們公司的軟體是給警察局用的，那是乙個對用來處理被逮捕的人的系統，此系統還需要收集臉部特徵和指紋資訊，並且，這個系統和會向fbi的系統提交這些資訊。當我們在測試這個系統的時候，我們一般都是用我們自己的指紋，當然，資料庫聯著的是我們的測試資料庫。不過，有一次，在我們測試完後，我們忘了把系統切換回生產庫，於是我們的測試資料庫就聯上了生產環境，於是我們的指紋資訊和**就散布到了其它系統中……清除我們警察局這邊的還好辦，但是，你需要波士頓警察局警司去法院簽字才能從fbi的資料庫中清除我們的資訊。點評：測試環境和生產環境的資料不要混在一起。
有一次，我需要向新系統中匯入一堆資料，因為資料量太大，需要5個小時，只能在夜裡來幹，在系統需要正式使用前2個小時，資料導完了，此時是凌晨4點。隨後，我需要刪除一些資料，於是我在sql命令地上輸入了「delete from important_table; where id=4」。是的，我沒有看到**還有個分號，天啊。點評：這就是加班工作的惡果。另，在delete之前最好先做一次select。
我把我的管理員口令提交到了乙個開源軟體的原始碼裡。點評：1）版本管理器裡的東西是刪不掉的。2）一些使用者和口令要hard code在**裡，所以，不要混用**使用的許可權和管理員的許可權，小心管理程式的執行許可權，為其註冊專門的使用者。
我為乙個很大的銀行開發軟體，在我的**裡，我為一段理論上根本不可能執行到的**加了乙個報錯資訊。有一天，不可思異的事發生了，這條報錯資訊顯示在了該銀行的1800個分行的超過10000個終端上——「如果你看到這個資訊，說明整個系統被****了，回家吧，祝你過得愉快！」點評：「假設是惡魔」，assume意為ass – u – me，意為——搞砸你和我。對於一些關鍵東西，永遠不要做假設。小心你言語中的——「可能、應該、覺得、不應該」等詞語，程式可不認這些東西。
我遠端登入到伺服器上加幾個防火牆規則。第一件我想幹的事是在不允許任何人的任何連線，第二件是，為某個埠開啟訪問許可權。不過，我在做完第一件事後就把配置儲存了，結果其生效了……點評：這樣的事經常發生，做遠端網路管理的人多少會有那麼幾次發生這樣的錯誤。在你將你的網路配置生效前，你得想一想，斷線了你是否還能登得上去。改配置不要太衝動，生效前檢查幾次。
我們的**中有乙個模組完美地工作了很多年了，只是**太亂了。我說服了我的老闆，我可以重寫這個模組，於是我花了三個星期來重寫這個模組。今天 ，我還記得，我的老闆站在我的後面看著我，而我在在流著斗大的法汗珠去fix被我重寫的「超級漂亮」的那個模組中乙個接乙個的bug。從那以後，我再也不重寫**了，除非有重大的利益。點評：這就所謂的屠宰式程式設計 。這個案例告訴我們兩個道理，1）維護**要用最最最保守的方法來進行。2）重構**前要像乙個商人一樣學會計算利益。當然，thoughtworks的諮詢師 一定會告訴你tdd，結對，極限等等方法告訴你如果實踐重構。但我想告訴你，乙個程式在生產環境裡執行好幾個年能沒有問題是一件很不容易的事，那怕其中的**再爛，你再看不過去，你都要有乙個清醒的頭腦明白這幾點，1）軟體的執行質量是遠遠大於**質量的，2）你的測試案例是遠遠小於生產環境的，3）軟體的完美的質量，是靠長時間的執行、測試和錯誤堆出來的，而不是某種方**。
乙個發生在我的領導身上。
我98年剛參加工作的時候，在某單位網路部門，一次，我們整個部門去給下屬單位培訓cisco路由器，結果我們發現帶去培訓地點的裝置少帶了集線器hub，裝置連不起來。於是領導很不高興，質問我們為什麼沒有帶集線器？那幾個對領導平時就不滿的老員工說辦公室裡沒有集線器了，都借給別的部門了。領導想了想，問我：「陳皓，我記得上次我給過你個集線器」，我說，「好像沒有吧，我記不起來了，什麼牌的？幾口的？」，領導說：「什麼牌子想不起來了，不過我記得那個集線器是乙個口的」。「乙個口的？！」，我心裡嘀咕著，「真敢說啊」。但我不敢接話了。那幾個老員工來勁了——「哪有乙個口的hub啊，乙個口的怎麼聯兩台電腦啊？」，領導說：「用兩個乙個口的不就行了」。領導這話一出，全場一片寂靜，無言以對……後來：我們所有的組員都離開了我們的這個領導，我們的這個領導今天還在那裡工作。我想告訴大家，很多時候該走的是領導（包括外企，我上一東家正在裁人，不過我覺得該被裁掉的應該是那些經理）。我們的領導經常出這樣或那樣的笑話，這讓我隨時隨地地警醒自己——「不要當乙個被人笑話的經理」，於是，今天我還在努力地學習技術。
另乙個發生在我身上
剛剛接觸linux的時候，還不是很懂，那時的pc還只有奔3，編譯公司的程式好慢啊，有時候為了調查乙個問題，需要不斷地打log，來來回回地編譯，很不爽。直到有一天，硬碟不夠了，df一下，發現/dev/shm還有空間。於是，把全部程式copy了過去，發現編譯起程式超快無比，爽得不行。於是就把工作環境放在/dev/shm下了，連開發都放在這裡了。這一天，開發乙個功能，改了十來個檔案，加班很晚，覺得基本搞定，大喜，回家睡覺。第二天一來，發現/dev/shm下空了，乙個檔案都沒有了，問同事，同事不知，同事還安慰我說，上次他的檔案也不知道被 誰刪了，於是我大怒，告老闆！老闆也怒，發郵件到整個公司質問大家誰刪了陳皓的程式，無人應答。it部門答，「昨晚唯一的操作就是重啟了linux伺服器，什麼也沒乾，不過我們天天備份伺服器，可以恢復」，it部門問我丟的檔案在哪個目錄下？於是，我reply to all – 「在/dev/shm下……」，哎，人丟大發了……後來：我很感謝我以前犯的這個錯，從那天以後，我開始立志學好linux，這個錯誤讓我努力，讓我發奮。所以，我想告訴大家——尤其是剛出道的程式設計師，你們要多多犯錯，要犯錯那種丟死人的錯，這樣你才會知恥而勇。
再來乙個發生在我同事身上的
後來：這個事後，我的那個同事，把rm命令改了名，並自己寫了乙個rm命令，把刪除的檔案先放到乙個臨時目錄下。而我也因為這個事情，到今天，每次當我在root目錄下使用rm時，敲擊回車的手都是抖的。（另，rm時永遠使用絕對路徑）這裡，我想告訴大家——犯錯不可怕，可怕的是不會從中總結教訓，同乙個錯犯兩次。
歡迎分享發生在你身上那些悲催的事。
程式設計師那些悲催的事兒
jonathan sampson在stakeoverflow上有這樣乙個貼子叫 confessions of your worst wtf moment wtf就是what the 的縮寫 譯文由酷殼網陳皓整理編譯 程式設計師那些悲催的事兒 我們公司的軟體是給警察局用的，那是乙個對用來處理被逮捕的人...
摘錄《程式設計師那些悲催的事兒》
裡面這一條很棒 我們的 中有乙個模組完美地工作了很多年了，只是 太亂了。我說服了我的老闆，我可以重寫這個模組，於是我花了三個星期來重寫這個模組。今天 我還記得，我的老闆站在我的後面看著我，而我在在流著斗大的法汗珠去fix被我重寫的 超級漂亮 的那個模組中乙個接乙個的bug。從那以後，我再也不重寫 了...
程式設計師那些悲催的事兒下
乙個發生在我的領導身上。我98年剛參加工作的時候，在某單位網路部門，一次，我們整個部門去給下屬單位培訓cisco路由器，結果我們發現帶去培訓地點的裝置少帶了集線器hub，裝置連不起來。於是領導很不高興，質問我們為什麼沒有帶集線器？那幾個對領導平時就不滿的老員工說辦公室裡沒有集線器了，都借給別的部門了...