可能你一行不好的代碼也從來沒有寫過。這是有可能的，但在現實中又不太可能。

現實情況是，和這個星球上的其他所有程序員一樣，你會產出安全漏洞、UI元素偏移，等等等等的代碼。這并不能說明你是一個不好的開發人員。只是因為你是人類而已——一種不可避免會犯錯的生物。

正是這種每個開發人員都有的“人性”缺陷，驅使那些優秀的開發人員敢于承擔代碼和底層基礎架構的不足，有準備有計劃地行動。下面是他們將做的事情。

[[147622]]

假設

幾年前，Netflix開源了Chaos Monkey和Simian Army的其他部分（Simian Army是一套工具，用來管理基于云的軟件）。從本質上說，Chaos Monkey的范圍貫穿亞馬遜Web服務的基礎設施，能夠隨意終止實例。從根本上說，它是一種通過創建最壞的可能方案來做最壞打算的方法。

正如Netflix的Cory Bennett和Ariel Tseitlin于發行之時在博客上這樣寫道，“代碼會失敗，并且你越不希望失敗或一點也沒有準備的時候，反而更加不可避免會出現故障。如果你的應用程序 不能容忍實例故障，那么你是愿意凌晨3點被召喚呢還是在辦公室里通宵？”

使用不可預測的方式來模擬故障，Netflix強迫注重基礎設施的彈性。與其假設***的情形，還不如做一個最壞的打算。這樣我們就能愉快地進入下一個進程了。

測試

上面我們說了一個提高基礎設施的偉大方法，那么代碼呢？

Jeff Atwood，一個程序員的答案是：“你需要折騰你的代碼。”他寫道：

我相信，每個專業程序員職業生涯的一個關鍵轉折點，就在當你意識到你才是自己***的敵人，以及減輕這種威脅的唯一辦法就是接受它的時候。將自己當作***的敵人。打破你的用戶界面。打破你的代碼。折騰你的軟件。

在實踐中，這意味著“程序員至少需要對常見錯誤有一定的了解，然而，很多程序員往往不會這么去做，甚至是反著來。”這意味著你作為“編程之神”的責任也包括成為“測試之神”，通過“折騰”代碼積極地來消除里面的錯誤。

Andre Medeiros補充認為我們應該對調試“精益求精”，因為開發人員需要對他們的代碼做更多的事情。

“為了防止bug，你寫出來的代碼得讓任何程序員都覺得簡單。為了修復bug，你得理解你的代碼。為了精密地了解代碼，你需要列舉和驗證你的假設，如果有必要，你還需要構建調試工具。”

貧民窟上的摩天大樓

當然，對于我們的代碼，其***的問題之一是，它繼承了如此多其他的代碼。特別是在已建立的企業中，我們常常構建在舊代碼上，從而導致了各種后續延伸問題。

以下是Zeynep Tufekci的精彩描述：

將它比喻成造房子的話——也就說你將要在已經造好的底層基礎上造二樓。但房子一開始造的時候并沒有造好，沒有打好地基，你 也不知道哪面是承重墻。你只能盡可能地去猜，然后造好了一個樓層——用你的手指。然后你接著這樣做。很多舊但控制著基礎設施關鍵部分的軟件系統就是這樣運 行的。在某一段時間內它也的確是可以工作，但每一個新樓層的建造意味著增加了更多的漏洞。我們正在代碼中建設貧民窟上的摩天大樓——而且，還在地震區。

很顯然，我們對于改善這種情況束手無策，除非我們能夠致力于去除技術債務。

但也許，只是也許，在心甘情愿折騰代碼的過程中，你會發現消除技術債務是如此之重要。

譯文鏈接：http://www.codeceo.com/article/good-programmer-deal-bad-code.html
英文原文：How Good Developers Deal With Bad Code