意念的傳達

核心問題#

當架構團隊完成設計決策後，如何將這些決策精確地傳達給數百位實作者？如何確保每個人對同一份規格的理解完全一致？這是一個看似簡單、實則極其困難的問題。

架構設計的價值，完全取決於它能否被精確地傳達與實作。再偉大的設計，若在溝通過程中走樣，最終產品仍會偏離原始意圖。

手冊（manual）是架構師最重要的溝通工具。它是產品外部規格的完整說明，描述使用者所能看到的一切——所有介面、功能與行為——同時刻意避免涉及內部實作細節。

手冊必須由少數人負責撰寫，以確保用語、風格與概念的一致性。當多人各自撰寫不同章節時，即使每個人都寫得很好，整體仍可能出現術語不統一、邏輯不一貫的問題。

Brooks 強調，手冊的撰寫必須極其謹慎：

除了散文式的描述，Brooks 主張應同時提供形式化定義（formal definitions）——使用精確的符號語言來描述規格。

形式化定義的價值在於精確性，而非可讀性。自然語言天生具有模糊性：同一句話，不同的人可能有不同的理解。形式化定義則消除了這種模糊地帶，每一個符號都有明確的語義。

然而，形式化定義也有其局限：

最佳做法是兩者並存：散文描述提供理解與脈絡，形式化定義提供精確與權威。當兩者出現矛盾時，必須明確指定形式化定義為權威標準。

一種更極端的做法是直接將規格寫成可執行的程式碼——例如一個模擬器或直譯器。這種方式的最大優勢是：實作本身就是規格，所有模糊地帶都被自動解決，因為程式碼必須對每一種情況做出明確的處理。

但這種做法也有明顯的代價：

直接融入的方式在現代軟體開發中有了新的面貌——可執行規格（executable specifications）、契約測試（contract tests）與參考實作（reference implementations）都是這個概念的延伸。

再好的書面規格也無法預見所有問題。日常開發中，實作者必然會遇到規格未涵蓋或措辭模糊的情況。Brooks 描述了兩種處理機制：

架構團隊應舉行每週例行會議，由首席架構師主持。這些會議的主要目的是腦力激盪與討論，而非即席做出最終裁決。會議中鼓勵自由發言，所有決議在會後由首席架構師做出最終定奪，並以書面形式公布。

當架構師與實作者之間出現爭議時，需要正式的裁決機制。架構師擁有最終決定權，但在做出裁決之前，必須充分聆聽實作者的意見——實作者往往能提出架構師未考慮到的技術限制或更優的替代方案。

所有會議決議都必須記錄並公布，確保所有相關人員都能獲得一致的資訊。

在日常工作中，實作者會不斷以電話或口頭方式向架構師詢問規格中的疑點。Brooks 建議架構師維護一份電話日誌（telephone log），記錄所有問答。

電話日誌的運作方式：

如果缺乏電話日誌這樣的機制，同一個問題會被不同人重複詢問，而且不同的架構師可能給出不一致的答案。這種不一致性一旦滲透到實作中，將造成系統行為在不同部分之間的微妙差異——最難除錯的那種缺陷。

獨立的測試團隊扮演著概念完整性的最後守門人角色。測試團隊是使用者的代言人（advocate for the user），他們的工作是依據規格說明來驗證實作——不是依據實作者的理解，而是依據架構師書面定義的行為。

測試團隊的關鍵特質：

Brooks 指出，當同一份規格有兩個以上的獨立實作時，規格中的模糊之處會被迅速暴露。不同的實作者會從不同角度閱讀同一份規格，對模糊措辭做出不同的解讀。這些差異一旦浮現，就迫使架構師回頭將規格寫得更精確。

System/360 正是這種做法的成功案例——多個機型各自獨立實作同一套架構規格，過程中不斷發現並消除規格的模糊地帶。