Marc Brooker 這篇文章討論了形式化方法在軟體工程實踐中的重要性，特別是在構建大型系統、分散式系統或關鍵的低階系統時，在這些情況下不使用形式化方法很可能會浪費時間和金錢。
形式化方法並不便宜，也不是特別容易，並且並不適合每種軟體工程方法。
- 人們有理由相信形式化方法會增加成本，尤其是非經常性工程成本。
我的經驗是，這並非事實，原因有二：
- 首先是返工：軟體工程在工程領域有些獨特，因為設計和施工往往同時進行，許多施工可以在沒有進行太多設計的情況下開始。這是軟體的一大優勢 - 它的可變性是它征服世界的原因之一 - 但也可以透過將設計迭代轉變為實施迭代來顯著增加設計迭代的成本。
- 是變更成本：一旦 API 或系統有了客戶，更改它的成本和難度就會增加很多倍。
使用 API 隔離系統行為是一個絕妙的想法。事實上，我認為這是整個軟體工程中最重要的想法之一。
海勒姆定律：
- 如果 API 有足夠數量的使用者，那麼你在API合約中倡導的什麼承諾並不重要：系統的所有可觀察到的行為都將依賴於某人（上下文、具體情況）。
海倫定律提醒我們這種方法的侷限性：使用者最終將依賴於 API 的每一個可以想象的實現細節。這並不意味著改變是不可能的。
在我的職業生涯中，我參與過許多完全重新實現 API 背後系統的專案。這僅僅意味著改變是昂貴的，而像 API 這樣的抽象並不能有效地改變這一現實。
透過節省返工成本並儘早完成介面更改，正式的設計工作可以顯著提高軟體構建過程的速度和效率。
形式化方法有助於更快地構建系統，並透過快速探索最佳化和約束條件來建立更快的系統。
哪些工具？
形式化方法和自動推理是廣闊的領域，擁有大量的工具。在我的職業生涯中，在我的大型雲系統領域，我發現以下工具很有用（但我相信有些工具如果我瞭解的話會很有用）。
- P、TLA+和Alloy等規範語言及其相關的模型檢查器。
- 確定性模擬工具（如turmoil）允許透過模糊測試以及透過測試搜尋狀態空間的原則性方法。
- 像Dafny這樣的驗證感知程式語言和像Kani這樣的程式碼驗證器。我對這些工具並不是很瞭解，而且使用它們的次數比其他工具少很多。
- 數值模擬技術。我傾向於構建自己的技術（正如我之前所寫），但目前已經有很多框架和工具了。
- 白板形式化方法。這些方法包括：在白板上或設計文件中繪製決策表、真值表、顯式狀態機等。
但是，就這篇文章而言，我們不想太過糾結於“驗證實現是唯一值得的最終目標（實踐是檢驗真理的唯一標準）”這一想法。這確實是一個值得的目標，但我發現使用 TLA+ 和 P 等工具在構建之前更快、更具體地思考設計有很大的價值。
Brooker 文章的要點：
- 形式化方法有助於更快地構建系統，並透過快速探索最佳化和約束條件來建立更快的系統。
- TLA+ 和 P 等工具對於在實施前更具體地思考設計很有價值，有可能減少返工並提高效率。
- 形式化設計工作可以減少返工成本，提前解決介面變化問題，從而大大提高軟體構建過程的速度和效率。
- 形式化方法的價值因軟體型別而異。需求明確的系統或更接近 "物理定律 "的系統更能從形式化設計方法中獲益。
- 雖然形式化方法最初可能看起來成本很高，但一旦 API 或系統有了客戶，它們可以最大限度地減少返工和變更費用，從而降低總體成本。
- 形式化方法尤其適用於將系統行為與應用程式介面隔離開來，鑑於海勒姆定律（系統的所有可觀察行為都會被某些人依賴），這一點至關重要。
結論
在設計階段使用工具來幫助我們思考系統的設計可以顯著提高軟體開發的速度，降低風險，並讓我們從一開始就開發出更最佳化的系統。對於我們這些從事大型複雜系統工作的人來說，它們只是良好工程實踐的一部分。