第六章 貫徹執行

這一章主要講述了文檔化的規格說明——手冊、形式化定義、直接整合、會議和大會、多重實現、電話日誌、產品測試。

手冊、或者書面規格說明，是一個非常必要的工具，盡管光有文檔是不夠的。手冊是產品的外部規格說明，它描述和規定了用戶所見的每一個細節；同樣的，它也是結構師主要的工作產物。隨著用戶和實現人員反饋的增加，規格說明中難以使用和難以構建實現的地方不斷被指出，規格說明也不斷地被重復準備和修改。然而對實現人員而言，修改的階段化是很重要的——在進度表上應該有帶日期的版本信息。手冊不但要描述包括所有界面在內的用戶可見的一切，它同時還要避免描述用戶看不見的事物。

手冊的作者必須註意自己的思路和語言，達到所需要的精確程度。一種頗具吸引力的作法是對上述定義使用形式化標記方法。畢竟，精確度是我們需要的東西，這也正是形式化標記方法存在的理由和原因。讓我們來看一看形式化定義的優點和缺點。形式化定義是精確的，它們傾向於更加完整；差異得更加明顯，可以更快地完成。但是形式化定義的缺點是不易理解。記敘性文字則可以顯示結構性的原則，描述階段上或層次上的結構，以及提供例子。它可以很容易地表達異常和強調對比的關系，最重要的是，它可以解釋原因。在表達的精確和簡明性上，目前所提出的形式化定義，具有了令人驚異的效果，增強了我們進行準確表達的信心。但是，它還需要記敘性文字的輔助，才能使內容易於領會和講授。出於這些原因，我想將來的規格說明同時包括形式化和記敘性定義兩種方式。

對軟件系統的體系結構師而言，存在一種更加可愛的方法來分發和強制定義。對於建立模塊間接口語法，而非語義時，它特別有用。這項技術是設計被傳遞參數和共享存儲器的聲明，並要求編程實現在編譯時的一些操作來包含這些聲明。另外，如果整個接口僅僅通過符號名稱進行引用，那麽需要修改聲明的時候，可以通過增加或插入新變量，或者重新編譯受影響的程序。這種方法不需要修改程序內容。

隨著時間的推移，一些決定沒有很好地貫徹，一些小事情並沒有被某個參與者真正地接受，其他決定造成了未曾遇到的問題。對於這些問題，有時周例會沒有重新考慮，慢慢地，很多小要求、公開問題或者不愉快會堆積起來。為解決這些堆積起來的問題，我們會舉行年度大會，典型的年度大會會持續兩周。

在大多數計算機項目中，機器和手冊之間往往會在某一天出現不一致，人們通常會忽略手冊。因為與機器相比，手冊更容易改動，並且成本更低。然而，當存在多重實現時，情況就不是這樣。這時，如實地遵從手冊更新機器所造成的延遲和成本的消耗，比根據機器調整手冊要低。

隨著實現的推進，無論規格說明已經多麽精確，還是會出現無數結構理解和解釋方面的問題。顯然有很多問題需要文字澄清和解釋，還有一些僅僅是因為理解不當。顯然，對於存有疑問的實現人員，應鼓勵他們打電話詢問相應的結構師，而不是一邊自行猜測一邊工作，這是一項很基本的措施。他們還需要認識到的是，上述問題的答案必須是可以告知每個人的權威性結論。一種有用的機制是由結構師保存電話日誌。日誌中，他記錄了每一個問題和相應的回答。這種機制很不正式，但非常快捷和易於理解。每周，對若幹結構師的日誌進行合並，重新整理，並發布給用戶和實現人員。

項目經理最好的朋友就是他每天要面對的敵人——獨立的產品測試機構/小組。該小組根據規格說明檢查機器和程序，充當麻煩的代言人，查明每一個可能的缺陷和相互矛盾的地方。每個開發機構都需要這樣一個獨立的技術監督部門，來保證其公正性。

《人月神話》閱讀筆記06