《需求設計：建構使用者想要和需要的産品》——第2章 設 計 體 系2.1 為什麼應該建立設計體系

本節書摘來自華章計算機《需求設計：建構使用者想要和需要的産品》一書中的第2章，第2.1節,作者： [英]　克裡斯·布裡頓（chris britton） 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

第1章說過，要想做工程化的設計，就必須有一套設計體系。那麼本章我們就來看看能不能為it軟體的開發工作建構出一套具有工程學水準的設計體系，并且看看我們是否值得去建構這樣的體系。

本章分為三個部分。2.1節從下至上檢視整個設計體系，以解釋我們為什麼應該建立該體系。接下來的2.2節～2.7節，用從上至下的方式來觀察這套體系，使大家對設計之中的資訊流動情況有所了解。把這套體系中的所有部件都展示出來之後，筆者會在2.8節之中回到本章開頭所提出的那個問題上面。最後的2.9節是對本章所做的小結。

首先，我們從實作設計（implementation design）談起，實作設計指的就是程式設計。

程式設計是一項設計活動。盡管并不是所有的人都同意這個說法，但從筆者自己的程式設計經曆來看，确實如此。剛開始程式設計的時候，我們會提出一個設計猜想，這通常叫做程式模式。接下來，我們會編寫代碼來細化這個猜想，并且通過編譯、代碼檢查及測試等手段來進行分析。然而，從第1章的圖1-6中可以看出，程式本身并不能代表整個設計，至少對于業解決方案之中的程式來說，是這樣的。

https://yqfile.alicdn.com/587baee04ce90231bc4e13e878dfe5f0d11b11d7.png" >

當今的大多數程式都搭建在架構之上。圖2-1示範了架構這一概念。

架構的理念是：設定一套骨幹代碼（skeletal code），其中可以放置各種代碼片段（code segment），這些片段用來實作使用者所需的功能，而骨幹代碼，則會把多個代碼片段整合起來，并提供一些常用的系統設施，如安全保護、消息傳遞以及系統管理等。

比如，有很多架構都支援mvc（模型—視圖—控制器）模式。該模式的基本思路是将輸入交給控制器（controller）去處理，而控制器則會通過模型（model）來通路資料，并且通過視圖（view）把資料展示出來。我們為模型、視圖及控制器分别編寫代碼，然後這些代碼會插入mvc架構之中。

架構通常由軟體廠商所提供。很多制作應用程式開發軟體的大型廠商，都有自己的架構，而且通常不止一套，此外，我們還可以找到很多開源的架構。不過，應用程式的開發者需要根據自身的需求，來對廠商所提供的架構進行擴充。對于多層應用程式（multitier application），尤其需要這樣做，因為大多數廠商所提供的架構，都位于一台計算機的範圍之内。

開發架構的時候，我們可以把程式員必須要完成的工作分成三種：架構本身的開發、功能代碼的開發以及常用工具的開發。此處的常用工具是指一些以程式設計手段實作出來的功能，例如，發送電子郵件、把一系列資料轉化成一份pdf檔案，以及回報錯誤等。圖2-2示範了這三種程式設計工作。

https://yqfile.alicdn.com/ffc2ec5cb93644aecc0dcf4223d7699bcaba1c88.png" >

了解上述知識之後，我們現在假設自己是一名程式員，并且需要編寫某個新的功能。那麼，在開始寫代碼之前，應該先知道下列四個方面：

使用者界面的設計（user interface design）：使用者界面的布局、使用者輸入的内容、程式需要對每項輸入所做的處理，以及程式需要輸出的顯示内容。

資料庫的設計（database design）：資料庫或者非資料庫的檔案所具備的結構。

內建設計（integration design）：要發送給其他應用程式的資訊（如果有），或是需要從其他應用程式那裡接收的資訊（如果有）。

技術設計（technical design）：標明自己所要使用的架構和軟體，并且設計一些公用的代碼，使架構、管理機制和操作機制能夠運作得更好。

就這四個方面來說，使用者界面的設計、資料庫的設計，以及技術設計，在整個設計體系裡面的位置，處在實作設計之上。至于內建設計的位置，我們稍後再談。

上述三種設計，需要由使用者界面設計者、資料庫設計者以及技術設計者來承擔。必須指出的是，這三種設計者說的是三種角色，而未必是三個不同的人。對于小型的應用程式來說，這三種角色完全可以由程式員一個人來扮演。但是要注意，這些設計不應該交錯地進行。比如，如果把使用者界面交給編寫代碼的程式員來做，那麼這位程式員不應該在每寫完一小段代碼之後，就去稍微設計一下使用者界面，或者說，他不應該等到必須牽涉使用者界面的時候，才去設計界面之中的某些内容。這一點是需要加以說明的。在使用者界面的設計之中，字型大小、按鈕位置以及顔色等外觀方面的因素，調整起來較為容易，由于它們不會對代碼産生太大影響，是以可以留到項目後期再做決定，然而像界面之間的切換、每個界面所顯示的資料，以及每個按鈕的功能等問題，則應該作為一個整體來進行設計。把這些内容視為一個整體，可以使我們分析出這套設計方案是否較為完備，并且使我們能夠仔細地判斷出該方案使用起來是否比較容易。這對于資料庫設計和技術設計來說，也是類似的。

筆者這麼說，可能有人不同意，因為我們畢竟也可以在程式設計的時候，發現設計之中的某些問題。沒錯，有的時候确實是如此。第1章曾經指出，這正是設計的本質特征，也就是說，細節設計總是有可能給宏觀設計提供回報。軍事上有句話，叫做“一碰到敵人，計劃就全亂了”，但這并不是說根本用不着做計劃。相反，計劃做得越好，修改起來也就越友善。設計也是這樣，把宏觀設計做出來之後，可以更好地看到修改該設計方案所引發的後果，于是當我們發現問題時，也就更有可能找到最佳的解決辦法。

那麼，使用者界面、資料庫以及技術方面的設計者要想完成其工作，必須知道哪些内容呢？他們需要知道的是：

該應用程式要為企業所做的事情。稍後我們将會詳細講解這一點。筆者把應用程式的功能分成多項任務（task），每項任務都表示某人于某時所做的某件事。是以，設計者需要知道有待實作的任務，以及每項任務所做的事情。

任務所使用的資料表。描述任務的時候如果不談資料，那麼這樣的描述通常就沒有太大意義。

與使用者有關的情況。設計者需要根據使用者所要做的事情，以及他們所要檢視和更新的内容，對這些使用者進行分組。

上面這三項資訊是緊密聯系在一起的，是以，它們應該放入同一個設計之中。筆者把這種設計叫做情境設計（context design）。

但是，在複雜的內建系統之中，情境設計可能會涵蓋多個應用程式及服務，而使用者界面的設計，卻隻會與某一個應用程式或服務相關聯。此外，對某個資料庫所做的設計，有可能同時要為多個應用程式或服務提供支援。是以，情境設計、使用者界面設計以及資料庫設計之間，并沒有簡單的一一對應關系。為此，我們需要用內建設計來展示各個部分之間的資訊交換和資源共享情況，以便把應用程式、服務及資料庫對情境設計的實作方式描繪出來。

最後，在做技術設計的時候，我們需要知道一些名額，如每小時或每秒鐘所需完成的任務數量，以及程式所需達到的可用性目标。

圖2-3畫出了這6種設計之間的關系，筆者給它起了個很沒有創意的名字，叫做六框設計模型（six-box model of design）。

https://yqfile.alicdn.com/ec342ce3d89468d2cdb5e3e14a465a07925edfae.png" >

你可能會問：我們有必要把設計分成這麼多種嗎？其實這樣劃分還是有些道理的。首先，資料庫設計的輸出結果，是資料庫模式，而技術設計的主要成果，則是架構代碼，換句話說，這兩種設計所輸出的成果，都是最終産品的一部分。其次，使用者界面的設計，是一種輕量級的設計。所謂輕量級，是相對代碼實作而言的，因為界面設計之中的某一句話，可以展開成很多行代碼。第三，各種設計之間可以複用某些資訊。情境設計之中的某些規範，可以不加修改地套用到內建設計上面，而且也可以在使用者界面設計之中複用。這與經典的工程設計不同，工程設計是要把內建設計轉化為使用者界面或資料庫的設計，而不是要将其分成使用者界面設計與資料庫設計這兩個元件。

筆者将在接下來的幾節之中，由上至下地描述這套模型，從情境設計一直講到實作。這幾節要強調的是各種設計所輸出的結果，而不是我們應該如何開發并分析這些設計，那是以後的各章所要談的話題。

筆者關注的主要是業務應用程式的開發，然而我想了一下之後發現，這個六框模型，其實對于其他類型的it應用程式來說，也可以适用，隻不過有的程式可能不需要進行資料庫設計或內建設計。對于某些應用程式來說，六框模型之中的一些元件可能完全用不到，例如，在設計并實作一款文字處理程式的時候，就不需要用到這麼多種設計。然而，對于其他一些非業務類的程式來說，盡管其情境設計的做法可能與剛才所說的有很大差別，但筆者仍然覺得這種設計是很有必要的。例如，在設計實時的火箭控制軟體時，依然應該進行情境設計，我們需要把各種控制項目及其行為确定下來，同時還要确定改變這些控制項目時所需遵循的規則。對于這種軟體來說，使用者界面的設計所針對的并不是人類使用者，而是一些電子測量裝置。此外，實時應用程式的實作，與普通應用程式相比，也有很大差異，因為我們必須在某個精确的時間段内執行某種動作。甚至我們還需要做資料庫設計，以確定資料之間的一緻性，進而使得該軟體能夠把近期的狀态記錄下來。內建設計可能也是需要做的，因為處理操作可能會分布在多個處理單元上面。與實時程式類似，遊戲程式設計之中也可以使用六框模型，隻不過此處的情境設計，是指對遊戲情節所做的概述，而內建設計，則隻會用在多人遊戲之中。

現在我們回到商業計算的領域，分别用6節篇幅來講述早前所說的那6種設計。