程序員那些悲催的事兒

<本文轉自酷 殼 – CoolShell.cn 做者 陳浩>

在StakeOverflow上有這樣一個貼子叫「Confessions of your worst WTF moment」（WTF就是What the fuck的縮寫），挺有意思的，我摘幾個小故事過來，但願你們在笑過以後能從中學到什麼——全部的經驗都是從錯誤中來的（我在其中加了一些點評）

咱們公司的軟件是給警察局用的，那是一個對用來處理被逮捕的人的系統，此係統還須要收集臉部特徵和指紋信息，而且，這個系統和會向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時永遠使用絕對路徑）這裏，我想告訴你們——犯錯不可怕，可怕的是不會從中總結教訓，同一個錯犯兩次。