再讀「人月神話」(2)－－關於架構

梭羅：「問題不在於你看著什麼，而是你看出了什麼」

重讀人月神話，方知這幾年，仍只是如來佛手中的小猴崽子......
我們來探討人月神話在架構及設計上的看法：

首先是整體概念性： 軟體工程並不用像蓋教堂一樣要花好幾世紀的時間。但是，因概念的不統一而造成問題的情況，卻遠比蓋教堂還糟。這肇因於我們往往不採用主設計師的一系列想法，而是把設計這件工作切割成好幾個部分，然後分配給一群人去做。 我主張在系統設計時，保有概念整體性(conceptual integrity)是最重要的原則。寧可忽略掉某些新奇或更好的特色，來反映同一組設計理念，也不要蒐羅了一大堆很棒，但彼此無關或合不來的構想。

要做到概念性整體這點，我們發現，勢必須要有一位總工程師或是架構師的角色，且必須有深厚的經驗及技術，方能達成這項要求。

避免發生錯誤的設計方式

做好定義以防止誤解 最致命也最棘手的錯誤莫過於系統錯誤。這肇因於各個組件的開發人員做出了彼此不協調的假設，之前討論的概念整體性，就是針對這個問題所提出來的解決方案，簡而言之，具備了概念整體性，不但使軟體易於使用、易於開發，也比較不容易發生錯誤。 這做法意味得在架構上付出勤勉、辛苦的代價。貝爾電話實驗室的V.A.Vyssotsky說：「把產品定義清楚是非常關鍵的工作，有太多大多的失敗都源自於自始至終都搞不清楚要做的是什麼東西。」 詳細的功能定義、詳細的規格說明、規範良好的防錯設施與錯誤處理技術，都有助於減少發生系統錯誤的可能性。 規格審查 早在進入程式編寫階段之前，規格文件就應該先由其他獨立的測試小組進行審查，以確保規格的完整和明確，開發人員本身則不適合做這樣的工作。 由上而下的設計方式 Niklaus Wirth在1971年提出了一篇非常亮麗的論文。將整個系統開發工作劃分出架構、實作和實現，便是基於這種觀念的具體做法；更進一步來說，不論是架構、實作和實現，都可以透過由上而下的方式做出最佳的成果。 Wirth 提出來的是一個持續細分精製的步驟(refinement steps)。一開始，先勾勒出粗略的工作定義和執行方案以得到主要的結果。然後對此定義做更深入的探討，看看結果跟我們真正要的東西有何不同，並把方案 中幾個大的步驟細分成更小的步驟，於是，在工作定義中的每個細分精製過程都演變成解決方案演算法的細分精製，同時也可能伴隨著某個資料結構的細分精製。 透過上述的過程，就可以界定出解決方案的模組(module)。或是其他能夠獨立進行更進一步細分精製的資料，而模組化的程度便決定了軟體適應變動或修改的能力。 Wirth提倡每個步驟都應該盡可能運用高階(high-level)的表示方式，只彰顯出概念，而細節則隱藏起來，留待需要更進一步細分精製的時候再處理。 一 個良好的由上而下設計方式(top-down design)可以避免掉許多錯誤，這可從幾方面來說明。 首先，由於結構與表示方式變得很清楚，所以更容易描述出精確的需求和模組功能； 其次，藉由分割並 明確定義出獨立模組的過程。可以避免系統錯誤； 第三，隱藏細節將使結構中的缺陷更容易被突顯出來； 第四，每一次細分精製的步驟，都可以對該步驟的設計成果進行測試，這使得測試工作可以提早進行，並把測試的焦點集中在屬於該步驟中較為適當的細節層次。 這種逐步細分精製的過程並非只進不退，如果在某個細節上遭遇到意想不到的混亂，就有可能再回到較高的層次重頭再來，事實上這種情形很常發生。但你會比較容易精確判斷出何時、或為什麼該壯士斷腕重 新設計。 有許多爛系統就是因為當初捨不得放棄，結果一直架在不良的設計基礎上做些治標不治本、疊床架屋的違章建築，由上而下的設計方式可以減少這種做法的誘惑。 Brooks認為由上而下的設計方式是這十年間最重要的一個新的軟體開發形式。

在決定怎麼做之前，重要的是知道要做什麼。
而且要每個人都清楚知道作的是什麼，所以要有清楚的定義。
可是團隊中還是會有搞不清楚或是只想依自己方法幹的人，因此有一段時間我們需要規格審查，不斷地review，以確定大夥兒都清楚知道。

另外，架構師要清楚的了解：
架構旨在說明做什麼，而實作是說明如何做。

架構師與實作人員的互動：
＊記住實作人員有發揮創意完成實作的責任，所以架構設計師只能建議，不能命令。
＊在建議時，永遠只提出一個能夠符合規格的實作方式，同時也接受其他能夠達到目標的方案。
＊默默地，私底下提出建議。
＊準備為提出的建議付出喪失信任的代價。

所以要做好架構，必定要有清楚的文件指導。
這我們下次再來談。