為什麼我們不同意羅伯特·馬丁的主張： “缺陷是程式設計師的錯。造成缺陷的是程式設計師，而不是語言。” 我說這是他的哲學的重大缺陷。

從表面上看，這聽起來很明顯。缺陷來自程式碼，程式設計師編寫程式碼，因此缺陷來自程式設計師。

許多最討厭的bug來自這些元件：單獨隔離時正確，但以危險方式互動呼叫時候出現Bug。這稱為功能互動錯誤。您可以證明這既是人的錯，又不是人的錯，也不是經理的錯，誰知道是誰的錯呢；另一組危險的bug來自模稜兩可的需求。有多種方法可以完全合理地解釋需求，即使客戶不知道他們打算使用哪一種詞語來表達。

功能互動和模稜兩可的需求的兩者錯誤可能來自於缺乏正式規範這樣的前期設計方法。因此，您可以說這也是程式設計師不編寫規範的錯。

“程式設計師建立缺陷”這個更大的問題是世界觀的基本問題。實際上，其遠不如作為我們可以用來理解缺陷的“解決方式”的價值重要。如果我們知道缺陷來自何處，就知道我們需要做什麼來進行管理。

“缺陷是程式設計師的錯”的世界觀如何告訴我們什麼解決手段呢？它說減少缺陷的唯一方法是提高程式設計師的紀律性（banq注：把焦點聚焦在“人”身上，而不是就事論事，聚焦在“事情”上）。程式設計師受過足夠的紀律約束，就沒有任何東西可以導致缺陷。馬丁本人將他的世界觀描述為：

原因：

1. 在時間表壓力下，太多的程式設計師採用草率的捷徑。
2. 太多其他程式設計師認為這很好，並提供掩護。

顯而易見的解決方案：

1. 提高軟體紀律和專業水平。
2. 切勿為草率的工作找藉口。

這就是為什麼馬丁建議程式設計師做：

• 單元測試（專門用於測試驅動的開發）
• 程式碼審查
• “清潔程式碼”
• 配對程式設計

這就是為什麼馬丁將可空型別之類的語言特性稱為“黑暗之路”，而形式規範則稱為“ 閃亮 ”。他的解決方案都與專案的結構、程式設計師使用的工具、所處的環境等無關。

注意這給我們帶來的好處！因為所有缺陷都來自程式設計師，所以我們只能在很窄範圍談論消除缺陷的事情。也許Bug是每個人都過度勞累，我們需要僱用另一個程式設計師嗎？如果我們的微服務架構使某些型別的錯誤更有可能發生怎麼辦？仍然是你沒有紀律。

在安全科學界，這被戲稱為“人為錯誤”。人為失誤是人們停止調查的地方。只是替罪羊，讓更廣泛的體系擺脫蘇格蘭的束縛。不要問裝置是否過時，培訓計劃資金是否不足或官方程式是否與地面現實脫節。當所有缺陷都是人的錯時，除了責怪人類之外，我們沒有任何其他工具可以解決缺陷。這對於我們的目的來說是完全不夠的。

我想舉一個例子說明“缺陷是程式設計師的錯誤”和“缺陷是系統的複雜屬性”之間的鴻溝：早在2018年，JavaScript世界就發生了巨大的糾纏，因為一個被廣泛使用的軟體包被惡意參與者接管了。每個人都在譴責這些壞人。許多人指責原始軟體包的維護者將其提供給惡意行為者，許多人指責那些升級了依賴關係而未先稽核程式碼的公司。我不是JavaScript世界的一部分，但想練習我的事故分析技能，所以我參與其中。最終分析花了兩個月的時間來撰寫並確定了更廣泛系統的15個屬性，這些屬性使攻擊變得可行，並且有可能在未來再次發生。其中一些易於修復，而其他一些則涉及可用性和安全性之間甚至安全性與不同安全性之間的基本權衡。所有這些都只是想責怪程式設計師而錯過。

（banq注：將注意力焦點從人身上轉移到事情上，還能避免道德綁架）

“缺陷是程式設計師的錯”聽起來不錯，但它無助於我們修復缺陷。