Michael Feathers希望消除錯誤能驅動設計

Michael Feathers因其著作《高效操作遺留程式碼》（ofollow,noindex">Working Effectively With Legacy Code ）一書而廣為人知。他發現錯誤中存在著一些值得關注之處，但他也承認大部分開發人員並未投入時間去關注這些錯誤。在他看來，很多錯誤解決機制就是採取某種程度上的放棄。在 Explore DDD 2018大會 上，Feathers做了主題演講，探討消除錯誤如何驅動軟體系統的設計。

針對領域驅動設計（DDD）大會的主題，Feathers在演講一開始就給出了對“領域”（Domain）的五種定義。他在這些定義中發現了一個共性，即領域就是一種範圍，一些領域是隨意構造的，也有一些是人們創造的。正因為領域是隨意構造的，因此人們可以重新塑造和擴充套件領域。雖然人們可以直接使用DDD模擬並適應不斷變化的業務流程，但為了更好地應對乃至消除錯誤，Feathers建議應對領域做盡可能類似的更改。

Feathers指出，領域擴充套件可能會導致一些不和諧因素，因此必須慎重。Feathers就此舉了兩個例子，一個是在可選日期中輸入了二月三十日，另一個是在程式語言中允許對陣列賦以負的索引值。對於前者，人們非常易於理解簡單域模型是如何允許這種非法情況的發生。但是對於負的陣列索引值，情況則恰恰相反，對此應丟擲一個錯誤。一旦這樣的技術可用，並被人們按有效的語法採納，那麼我們就會意識到領域擴充套件對此類情況是非常有用的。

Feathers提及，他探索錯誤的部分靈感來自於Joe Duffy部落格中對微軟的Midori作業系統研究專案 的論述，尤其是對錯誤模型l 的分析。Duffy提及，“錯誤模型試圖回答的一個基本問題就是，'錯誤'是如何傳遞給程式員和系統使用者的？”這個看似簡單的問題，自然導致了“如何定義錯誤”的挑戰。Feathers沿此思路繼續推理，最終得到人們希望知道的是“為什麼我們會存在錯誤？”。換句話說，如果“錯誤”只是一個用於指代我們領域中不匹配概念的用詞，那麼我們應該怎麼做？

演講進而從領域的概念延伸到如何實際處理錯誤。在遇到錯誤時，人們主要存在三種做法。第一種做法是簡單地返回空值。這種做法消除了對任何錯誤原因的解釋，需要人們對空引用做額外的檢查工作，並且混淆了人們仍在處理錯誤的事實。另一種做法是丟擲異常。這種做法也許要優於返回空值，因為它可以給出了問題的一些相關資訊，但它仍需要呼叫者去處理異常情況。第三種做法是將錯誤作為領域的一部分。Feathers認為，“錯誤就是我們領域的一部分，因為錯誤可能會發生在我們的工作中”。很顯然，Feather提倡採用第三種做法。

擴充套件領域意味著提出問題，“我們真正希望會發生什麼？”。不應只是告訴他人錯誤的相關資訊，而應引入一些新概念去提供可操作資訊。一個例子就是使用空物件模式返回ItemNotFound 物件，其具體實現取決於具體的情況。

在演講中的最後，Feathers給出了Erlang的設計理念，並按英式風格概括為“保持冷靜，任其崩潰”。計算是與現實世界緊密聯絡的，因此在現實中計算可能會產生失敗。Erlang通過將現實情況囊括在領域之中，擴充套件了應用的領域。如果一種語言的整個領域可以使用這種方式擴充套件，那麼即便是更小的系統，都一定能受益於涵蓋錯誤的領域擴充套件。

檢視英文原文：Michael Feathers Wants Error Elimination to Be a Design Driver