程式碼之道

第5部分 (第1/4頁)

書包　網　。　想看書來

獲取反饋

在規範書付諸實現之前，越多的眼睛看到它，它就會變得越好，並且將來要求的返工也會越少。如果你想很容易就能獲得反饋，你也想別人很容易就能提出反饋，至少你要將規範書草稿放到SharePoint上，並進行變更跟蹤和版本控制。做得更好一點，你可以把規範書放到一個維基站點上去，或者貼在功能團隊主要活動區域的一塊白板上。

撰寫規範書的這個過程、反饋和變更管理需要有多正式呢？像我在前一個欄目討論的那樣（即本章的“停止寫規範書”那個欄目），正式的程度取決於溝通是否直接，以及溝通的“頻寬”有多大。在同一個共享區域、同一個時間、工作在同一個功能的人們，他們可以使用很不正式的規範書和過程；而在不同時區、不同時間、工作在不同功能的人們，他們則必須要有高度正式的規範書和過程。

不管怎麼樣，你想讓規範書隨時都可以修改，直到團隊認為它不需要再改為止。那你怎麼知道規範書不需要再改了呢？答案是，要等到測試團隊驗證規範書透過了所有的質量檢查。

整合質量檢查

這是我們目前正在使用的規範書最離譜的地方。各個部門不是把安全、隱私和許多其他問題當作質量檢查，而是把它們一節一節單獨地寫在了規範書中。這是個災難，原因是：

？ 規範書變得更大並且複雜得多。

？ 作者必須在各節中複製資訊。

？ 讀者對後面的節次重視不夠，導致嚴重的質量缺口。

？ 設計變得難以理解，因為它們的描述分散在多節之中。

？ 錯誤和缺口很容易被忽略，因為沒有一個節次對設計作了完整的描述。

？ 更新幾乎是不可能的，因為一個最新的改動會影響多個節次，牽一髮而動全身。

取而代之的是，採用適合於每一份規範書的質量檢查，它以一個清單的形式出現，並且每個人都能觸手可得。一開始的幾個檢查對於每個團隊都是一樣的：

？ 需求清楚、完整、可驗證、並與有效的應用範例關聯了嗎？

？ 設計滿足了所有的需求嗎？

？ 所有關鍵的設計決議都被解決並存檔了嗎？

接下去的一套質量檢查也相當基本：

？ 所有的術語都被定義了嗎？ ？ 有沒有相容性問題？

？ 安全問題解決了嗎？ ？ 故障和錯誤處理解決了嗎？

？ 隱私問題解決了嗎？ ？ 談到安裝和升級問題了嗎？

？ 使用者介面完全可達到嗎？ ？ 維護問題解決了嗎？

？ 為全球化和本地化準備好了嗎？ ？ 備份和恢復問題解決了嗎？

？ 對於響應和效能的期望是否清楚並可測量？ ？ 是否有足夠的文件用於支援故障檢修？

？ 原始碼插樁和可程式設計能力定義清楚了嗎？ ？ 有沒有潛在的問題會影響打補丁？

各個團隊還可以為他們自己或者他們的產品線增加更多的質量檢查，解決他們常常面臨的特殊的質量問題。

線上資料：規範書檢查清單（Spec　）。

這裡的關鍵是，設計節次對功能進行了完整的描述，而質量檢查保證了沒有東西被遺漏。是的，這意味著設計節次可能會變得非常龐大，以覆蓋所有需要涉及的領域。但這些領域不再是把功能按照每一個質量要求展開的累贅品（比如對話方塊的安全、對話方塊的隱私、對話方塊的可達到性等）。

取而代之的是，所有的領域將是功能的邏輯組成部分（比如應用程式程式設計介面、對話方塊、選單等）。重複消除了。每個功能組成部分完整地被描述出來，並且所有的質量要求都融合在了設計情境中。

作者注：一個奇怪而有趣的巧合：在本欄目發表之後的第二天，Office部門把他們的規範書模板做了簡化，只使用單獨的一個節次來描述設計，並且採納了我釋出的質量檢查清單。儘管我不能對這個改變邀功，但我的成就感著實得到了滿足。

書　包　網　txt小說上傳分享

差別在哪？

如果增加了所有的這些檢查和測試，你可能會懷疑我根本就沒有對規範書作出簡化。其實，這裡的最大改動是：

？ 節次的數量減少到了只剩下3個（需求、設計和問題）。

？ 設計在一個節次中得到了完整的描述。