在我職業生涯的某個時刻，我有幸參與了一個軟體系統的開發，其輸出決定了卡車的行駛路線。程式設計一直以來都是有趣且富有創造性的，但這是我第一次感到它同時也具有危險性和可怕性。卡車路由系統中的一個錯誤意味著現實世界中的物體會出現異常行為。時間表會被錯過，金錢會被浪費，客戶會感到憤怒。此外，與其他軟體系統不同，重新啟動或重新部署並不能解決問題 —— 車輛已經在外面行駛，因為對客戶承諾的時間表，重新啟動路線並不是一個選項。
因此，我們非常重視安全性和質量。我們有一套非常強大的測試，代碼由資深工程師仔細審查，並且我們有一個質量保證團隊 —— 但這並不意味著我們不會出錯。
錯誤！= 程式錯誤#
作為軟體工程師，我們被訓練去認為程式錯誤（例如，空指標、訪問超出數組長度的項目等）是我們應該密切關注的主要錯誤，因為它們會使我們的程式崩潰。我們也會犯這類錯誤，但我很快學到，雖然這些錯誤需要防止，但真正的大錯誤很少會導致崩潰，而是與我們的路由決策有關。空指標可以被錯誤追蹤工具捕捉到，修復可以在幾分鐘內重新部署。路由錯誤只能在仔細分析路線性能後捕捉到，通常需要幾周的時間來研究一條路線的盈利能力。
錯誤會發生#
當軟體系統達到某種複雜性閾值時，它們變得難以操作，容易無意中引入錯誤。這種情況發生的部分原因是系統的行為變得無法具體說明。再也沒有一個 “規範” 能夠適合任何一個人對系統應該如何運作的理解。相反，依賴於該系統的多方將對正確性有不同的定義。
你們中的一些人可能會爭辯說，有技術可以防止系統的複雜性達到這樣的程度，但有時我們會面臨已經超過複雜性閾值的系統。這篇文章處理的正是這類系統。
如何安全地開發一個你不理解的規範的系統？#
想像一下，你正在開發一個大型軟體系統，沒有任何一個人能夠確定什麼是 “正確行為”，那麼你如何安全地修改該系統呢？事實證明，有一種簡單但有效的技術可以實現這一點，我稱之為 三個變更。
三個變更#
你對代碼庫所做的每一個變更都可以分為三組：刪除、添加和行為變更。刪除將從系統中移除行為（例如，刪除代碼）。添加將為系統添加新行為（例如，添加新功能），最後，變更將改變系統的行為。
行為刪除的測試策略#
當你進行刪除時，只有兩種可能性。要麼你刪除的是在其他地方使用的行為，要麼你刪除的是未被使用的行為。
第一種可能性會產生錯誤，第二種基本上是刪除死碼。因此，驗證刪除的正確性相當於確保你要刪除的代碼不被任何人或系統的其他部分使用。類型檢查器在這裡做了大部分的繁重工作，因此在實踐中，純粹的行為刪除通常產生錯誤的概率很低。
行為添加的測試策略#
為系統添加行為，通常稱為 “功能工作”，有一個很好的特性。通常，新行為是由一個個體或一個團隊密切合作引入的，在大多數情況下，會有一個規範或某種方式來定義新行為的正確性。
這很好，因為這意味著驗證添加的正確性相當於驗證新行為是否符合規範。
新行為通常也可以以漸進的方式發布（例如，使用功能標誌），以進一步減少錯誤的影響。
行為變更的測試策略#
改變系統的行為是三種變更中風險最大的。安全地改變系統的唯一方法是首先充分理解它在多種可能輸入下的行為，系統可以處於什麼狀態，以及它是如何失敗的。
重點#
- 除非你真正理解系統的運作，否則不要變更系統的行為。
- 設計你的系統，使新行為可以獨立於現有行為輕鬆添加。
- 設計你的系統，使代碼在需要時可以輕鬆刪除。@tef 有一篇文章叫做 寫出易於刪除的代碼，而不是易於擴展的代碼。
如何安全地改變一個軟體系統？#
- 三種類型的變更 你對軟體系統所做的每一個變更都可以歸類為以下三個類別之一或多個：
- 行為的添加
- 行為的變更
- 行為的刪除