優秀程式設計師是如何處理糟糕程式碼的

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

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

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

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

假設

幾年前，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的精彩描述：

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

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

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