程序員那些悲催的事兒 你可曾遇到
我們公司的軟件是給警察局用的，那是一個對用來處理被逮捕的人的系統，此系統還需要收集臉部特征和指紋信息，并且，這個系統會向FBI的系統提交這些信息。當我們在測試這個系統的時候，我們一般都是用我們自己的指紋，當然，數據庫連著的是我們的測試數據庫。不過，有一次，在我們測試完后，我們忘了把系統切換回生產庫，于是我們的測試數據庫就連上了生產環境，于是我們的指紋信息和照片就散布到了其它系統中……清除我們警察局這邊的還好辦，但是，你需要波士頓警察局警司去法院簽字才能從FBI的數據庫中清除我們的信息。
點評：測試環境和生產環境的數據不要混在一起。
有一次，我需要向新系統中導入一堆數據，因為數據量太大，需要5個小時，只能在夜里來干，在系統需要正式使用前2個小時，數據導完了，此時是凌晨4點。隨后，我需要刪除一些數據，于是我在SQL命令地上輸入了“DELETE from important_table; where id=4”。是的，我沒有看到哪里還有個分號，天啊。
點評：這就是加班工作的惡果。另，在delete之前最好先做一次select。
我把我的管理員口令提交到了一個開源軟件的源碼里。
點評：1)版本管理器里的東西是刪不掉的。2)一些用戶和口令要hard code在代碼里，所以，不要混用代碼使用的權限和管理員的權限，小心管理程序的運行權限，為其注冊專門的用戶。
我為一個很大的銀行開發軟件，在我的代碼里，我為一段理論上根本不可能執行到的代碼加了一個報錯信息。有一天，不可思異的事發生了，這條報錯信息顯示在了該銀行的1800個分行的超過10000個終端上——“如果你看到這個信息，說明整個系統被Fuck了，回家吧，祝你過得愉快!”
點評：“假設是惡魔”，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，這個錯誤讓我努力，讓我發奮。所以，我想告訴大家——尤其是剛出道的程序員，你們要多多犯錯，要犯錯那種丟死人的錯，這樣你才會知恥而勇。
再來一個發生在我同事身上的
01年，我們開發銀行系統，在AIX上開發，RICS6000很貴，只能在客戶那里開發，開發進度很緊張，慢慢地硬盤就不夠用了，系統中有大量的垃圾文件，于是需要清除一些文件，于是有一個同事寫了一個腳本，可以自動清除的各種不重要的文件，里面有一條命令大致是這個樣子“ rm -rf ${app_log_dir}/*”，意為清除程序運行的日志。為了使用這個腳本，需要在root用戶下運行，一開始還不錯。直到有一天，某人一運行，整個根就沒了。搞得整個團隊只能用一周前的備份重寫已寫好的代碼。后來，才發現原因是${app_log_dir}變量為空，于是成了“rm -rf /*”……
后來：這個事后，我的那個同事，把rm命令改了名，并自己寫了一個rm命令，把刪除的文件先放到一個臨時目錄下。而我也因為這個事情，到今天，每次當我在root目錄下使用rm時，敲擊回車的手都是抖的。(另，rm時永遠使用絕對路徑)這里，我想告訴大家——犯錯不可怕，可怕的是不會從中總結教訓，同一個錯犯兩次。
歡迎分享發一在你身上那些悲催的事。
屠宰式編程：使用這種風格的程序員，對重構代碼有著一種難以控制的極端沖動。他們幾乎會重構所有經手的代碼。就算是在產品在Release的前夜，當他在修正幾個拼寫錯誤的bug同時，其會修改10個類，以及重構與這10個類有聯系的另20個類，并且修改了代碼的build腳本，以及5個部署描述符。
【編輯推薦】
