隨著時間的推移，很多程序里都會慢慢積累一些看似沒用的或廢棄的代碼，沒人敢動它們，因為擔心會把程序能壞。我認為，這些代碼借助于人們對它的缺乏 了解，害怕修改程序——這其實是源于一種迷信，而非出于理智——而駐留在程序里，成為了一種具有最隱蔽形式的技術債務。你也許在處理這些代碼時會把程序能 壞，但你必須處理掉它們——為了堅守你的理智，為了保持程序的健康。

幾周前，一個主要由我負責的我們的基礎系統里的一個服務開始表現出反常現象。其中有一個線程的CPU使用率時不時會沖上100%，偶爾會減退平息， 但大多數會保持高位，留下一排讓人煩惱的Munin監控圖，它的每次沖鋒都像是對我的嘲弄。通過一些查找發現了兩個問題，我研究了好幾天，結果卻發現那只 是障眼法，根本不是問題的根源。

正好趕上假期，我把絕大部分的時間都花在了我們生產環境集群服務器的一個節點上，試圖能明白這個問題的成因(這個現象只在生產環境且有一定的并發時 才會出現，在測試環境中無法復制，即使加到10倍的負載)。從凌晨2點到4點，不知損失了多少腦細胞，我胡亂的在程序里加入bug調試，異常捕捉(盡管沒 有任何跡象顯示有異常拋出)的代碼，以及其它一些胡亂的，讓人后怕的沒用代碼。最終，我發現了在一個資源競爭的條件判斷中一個套接字標志可以被設置成 SO_WRITE，卻從來沒有被清除。這會導致在While(true)循環里的Selector.select()調用立即退出，而不是耐心的等待一個 網絡IO事件發生，這最終導致了一個自我循環的線程占用100%CPU負荷的現象。幸運的是，這個問題并沒有影響到這個服務的運行。修改了一下程序解決了 這個問題后(只是把一行代碼剪切到原位置的下兩行)，服務運行的非常的好，這個勞動節剩下的一個周末我在舊金山過的很愉快。

你必須解決它。

假期結束回到辦公室后，我向我那充滿耐心、熱心幫助的同事為此事說了一大篇解釋和抱歉的話，然而之后，我突然感覺到有些后怕，我在程序里留下了那么 多沒用的顯示log信息的、捕捉無意義異常的、其它的亂七八糟的代碼，我害怕去碰它們了。理由站不住腳，這是害怕去改動能夠正常運行的程序，盡管這些都是 迷信。

編程是一種科學，我們所有的系統都是基于其中的一些原則、約定和API(數學，POSIX，編程語言)。因為我知道這些各個層面上的知識，這些保證 了我不會產生沒有根據的懷疑和恐懼，我不會讓自己在這些問題面前嚇的不敢亂動。迷信在編程中是沒有用的——你可以問問任何一個能花上一兩天去跟蹤內存泄漏 問題的程序員。

我們面對的任務并不是“找出為什么運行異常”，而是去發現編程語言的哪種寫法觸發了這種不期望的行為。拋棄恐懼、誤解、抱怨的思想習慣，要想到計算 機程序有它自己的規則，我們擅長于理順它們。當然，最終，我的程序經過整理，完全按照我要求的方式精確的運行。它的工作流程我重新掌握的一清二楚，我又重 新控制了它。

如果你的程序讓你害怕，你應該解決它，直到你不再怕它為止。