設(shè)計真是件奇妙的事情，能造就璀璨的明珠，也能帶來一堆萬年不去核廢料；能讓人享受釋放智慧的樂趣，也能品嘗挫敗的沮喪。Why？

　　設(shè)計的過程

     工程角度，設(shè)計是一個過程,包含三種不同層次的活動：架構(gòu)設(shè)計，概要設(shè)計和詳細設(shè)計。三者由全局到局部，依次展開，逐漸深入細節(jié)，最終完成一個技術(shù)解決方案，給出可行的如何實現(xiàn)需求的答案。此三者的一般性過程如下：

　　架構(gòu)設(shè)計

　　目標(biāo)：定位全局，確定技術(shù)方案的方向、后續(xù)技術(shù)活動策略。

　　輸入：需求文檔。敏捷過程常常是是一組用戶故事。

　　輸出：架構(gòu)設(shè)計文檔。敏捷過程稱之為應(yīng)用全局視圖Application Overview。

　　角色：架構(gòu)師

　　任務(wù)：

　　1.分析需求，識別關(guān)鍵功能、質(zhì)量需求和約束

　　2.分析目標(biāo)系統(tǒng)為達成以上目的，需要哪些流程，流程中有多少環(huán)節(jié)，各環(huán)節(jié)涉及哪些角色，這些角色的職責(zé)及他們之間的協(xié)作關(guān)系。

　　3.將角色按邏輯分類抽象，變成子系統(tǒng)。角色的職責(zé)即是子系統(tǒng)的接口，角色間的協(xié)作關(guān)系即為各子系統(tǒng)間的關(guān)系。

　　4.各子系統(tǒng)內(nèi)部，根據(jù)職責(zé)拆分模塊，確定它們的交互方式。

　　5.針對關(guān)鍵功能，確定完成這些功能的流程，在時序上由各子系統(tǒng)，模塊協(xié)同工作的順序。

　　6.考慮各子系統(tǒng)的部署方式。

　　7.將各子系統(tǒng)、模塊轉(zhuǎn)換成實現(xiàn)語言的元素。如對于.NET，規(guī)劃各子系統(tǒng)有哪些namespace，namespace如何分配到assembly,assembly之間的依賴關(guān)系。再將assembly分配到project中。期間需要注意避免循環(huán)依賴，明確接口(作為接口的assembly和project)。

　　8.規(guī)劃project在SCM中的組織結(jié)構(gòu)。

　　9.根據(jù)質(zhì)量需求確定全局性的技術(shù)策略（方案）：如線程控制，錯誤處理，數(shù)據(jù)存儲等。

　　10.分析其余需求，驗證當(dāng)前方案是否能支持，根據(jù)發(fā)現(xiàn)的問題做必要調(diào)整。

　　概要設(shè)計

　　目標(biāo)：在具體實現(xiàn)語言層面上展開工作，確定每個project的主要類及交互過程和總體算法。

　　輸入：架構(gòu)設(shè)計文檔和需求。

　　輸出：概要設(shè)計文檔。

　　角色：高級程序員

　　任務(wù)：

　　1.設(shè)計提供暴露服務(wù)的接口的具體實現(xiàn)類，補充所需的相類，通常可按界面（接口）、活動和存儲三方面考慮。進一步落實對項目外接口的依賴關(guān)系和位置。

　　2.設(shè)計算法實現(xiàn)接口暴露的相關(guān)功能。

　　詳細設(shè)計

　　目標(biāo)：確定概設(shè)提出的每個方法的具體實現(xiàn)。

　　輸入：概要設(shè)計

　　輸出：偽代碼。

　　角色：程序員

　　任務(wù)：用偽代碼描述每個方法。

     這里看到的是一個按需求->系統(tǒng)->子系統(tǒng)->模塊->類->方法，自頂向下逐步求精的過程。

　　設(shè)計的技術(shù)

     技術(shù)角度，設(shè)計是一系列方法和工具，通過應(yīng)用這些方法和工具給出一個可行解決方案的描述。常用方法有：

     OO：面向?qū)ο蠓椒āＦ淠康氖墙y(tǒng)一問題的描述與解決方法，通過一致的抽象提高開發(fā)效率。核心思想是，將問題空間映射到計算機模型上，在計算機中建立一個同我們?nèi)粘８兄澜缦嗤哪Ｐ停鉀Q問題。實踐中，通過類描述問題空間的概念，通過類的消息描述這些概念的交互形成一個模型，再將模型落實到OOP的語言中，如C++，C#，Java等。

     AOP：面向方面的方法。期望將主要業(yè)務(wù)同這些業(yè)務(wù)中散落的支撐功能（服務(wù)）如日志，權(quán)限等分離。結(jié)合OOP應(yīng)用時，通過橫切點定義跨多個類的支持服務(wù)，由方面（特殊類）實現(xiàn)這些服務(wù)，再通過切入點連接方面與橫切點，達到運行時自動提供服務(wù)的目的。

     DDD：領(lǐng)域驅(qū)動的設(shè)計。采用傳統(tǒng)OO方法時，一般的需求分析結(jié)果是用自然語言描述的與OOD存在脫節(jié)，容易生造出問題域中不存在的概念，建立與實際需求不一致的模型。因此，從需求分析起，首先為問題域即領(lǐng)域建模，完全不考慮如何設(shè)計、實現(xiàn)，用客戶能理解的方法僅描述問題現(xiàn)狀。常用的建模方法是OOA，模型可用UML表達，也可以用類似框圖聯(lián)系，總是以能讓用戶明白這就是問題的描述，方便溝通為原則。

     在不斷使用這些方法的過程中，一些大師們發(fā)現(xiàn)了某些經(jīng)常重復(fù)的解決方案，便對它們進行了提煉和總結(jié)，以便后來者這能利用這些經(jīng)驗，提高工作效率和質(zhì)量，少走彎路。這些經(jīng)驗有：架構(gòu)風(fēng)格，架構(gòu)模式，設(shè)計模式和反模式。

　　架構(gòu)風(fēng)格

     架構(gòu)層次的，根據(jù)系統(tǒng)的架構(gòu)呈現(xiàn)出的總體特點進行架構(gòu)分類的方式。主要的風(fēng)格有：

　　1.客戶-服務(wù)器：系統(tǒng)分為客戶與服務(wù)端兩部分，客戶端發(fā)送請求，服務(wù)端執(zhí)行并響應(yīng)。

　　2.分層（級）架構(gòu)：系統(tǒng)按關(guān)注點水平分層，每一層為上層提供一個抽象。近一步，可將層分布到不同計算機上。

　　3.面向?qū)ο螅合到y(tǒng)分成單獨的可重用的對象，每個對象包含數(shù)據(jù)及處理它們的行為。

　　4.基于消息（事件）：系統(tǒng)各部分通過發(fā)送和接收約定格式的消息工作，無需關(guān)心實際的收發(fā)者。

　　5.面向服務(wù)(SOA)：系統(tǒng)通過約定的契約暴露功能，并根據(jù)這些契約工作。

　　6.基于組件：系統(tǒng)分解為邏輯的可重用位置透明的組件，通過明確定義的通信接口工作。

　　7.管道-過濾器：由管道連接過濾器一組，處理流經(jīng)的數(shù)據(jù)。

　　8.微內(nèi)核：分離最小功能核心和可擴展部分。

     它們在最高層次根據(jù)問題的類型給出了一般的解決方向。如：

　　1.通信問題:基于消息、管道-過濾器

　　2.部署問題：客戶/服務(wù)器、分層架構(gòu)

　　3.重用與可擴展：OO、基于組件、SOA

     但是，不同風(fēng)格并不是互相排斥的，相反，一個實際系統(tǒng)通常同時呈現(xiàn)出多種風(fēng)格。如一個分布系統(tǒng)，功能可通過語言無關(guān)的契約暴露，用OOP實現(xiàn)這些契約，實現(xiàn)對象又被組織成一個個組件，每個組件定義了彼此的通信接口，而通信又可是基于消息的，組件本身運行在一個支持插件的容器中，可隨時添加新組件，提供新服務(wù)。這里表現(xiàn)出了SOA、OO、Component、Messaging和Mico-Kernel多種風(fēng)格。

　　架構(gòu)模式

     一系列可重用的架構(gòu)設(shè)計方案，每個方案在滿足適用場景的前提下，解決一種或一類問題。經(jīng)典的POSA給出了一些常用的模式分類：

　　1.服務(wù)訪問和配置：包裝器(Wrapper Facade)、組件配置器(Component Configurator)、截取器(Interrceptor)、擴展接口(Extension Interface)

　　2.事件處理:反應(yīng)器(Reactor)、主動器(Proactor)、異步完成標(biāo)記(ACT)、接收-連接器(Acceptor-Connector)

　　3.同步:界定枷鎖(Scoped Locking)、策略化加鎖(Strategized Locking)、線程安全接口(Thread-Safe Interface)、雙檢查加鎖優(yōu)化(Double-Checked Locking Optimization)

　　4.并發(fā):主動對象(Active Object)、監(jiān)視器對象(Monitor Object)、半同步/半異步(Half-Sync/Half-Asynce)、領(lǐng)導(dǎo)者/追隨者(Leader/Followers)、線程特定存儲器(Thread-Specific Storage)

　　5.資源獲取:查找(Lookup)、懶加載(Lazy Acquistion)、預(yù)加載(Eager Acquistion)、分步加載(Partial Acquisition)

　　6.資源生命周期:緩存(Caching)、池(Pooling)、協(xié)調(diào)器(Coordinator)、資源生命周期管理(Resource Lifecycle Manager)

　　7.資源釋放:租約(Leasing)、清除者(Evictor)

　　此類模式給出了全局性問題的一般處理方案，大都是關(guān)于子系統(tǒng)、模塊及相互之間關(guān)系的粗粒度的描述。

　　設(shè)計模式與反模式

     設(shè)計模式指OO的設(shè)計模式，是可反復(fù)使用的代碼經(jīng)驗總結(jié)。通過GoF經(jīng)典的《設(shè)計模式》廣為人知。GoF將它們分類為：

　　1.創(chuàng)建型：簡單工廠(Simple Factory)、工廠方法(Factory Method)、抽象工廠(Abstract Factory)、創(chuàng)建者(Builder)、原型(Prototype)、單例(Singleton)

　　2.結(jié)構(gòu)型：外觀(Facade)、適配器(Adapter)、代理(Proxy)、裝飾(Decorator)、橋接(Bridge)、組合(Composite)、享元(Flyweight)

　　3.行為型：模板方法(Template Method)觀察者(Observer)、狀態(tài)(State)、策略(Strategy)、職責(zé)鏈(Chain of Responsibility)、訪問者(Visitor)、調(diào)停者(Mediator)、備忘錄(Memento)、迭代器(Iterator)、解釋器(Interpreter)

它們在代碼層面給出解決上述三類問題的一般做法及使用場景。

     設(shè)計模式如紅日般普照大地，光芒萬丈，導(dǎo)致做OO的言必稱設(shè)計模式，不用上幾個都不好意思拿去見人。免不了被亂用、誤用，明明需要避光保存的，偏偏加個LED增加照明，還曰節(jié)能、低碳。所以不得不需要反模式來撥亂反正。反模式說明了，當(dāng)在錯誤的時間，錯誤的地點，使用了錯誤設(shè)計模式后，出現(xiàn)的嚴(yán)重后果，提醒人們過猶不及。

　　設(shè)計的人員

     今天，從人員角度，設(shè)計是一系列扮演不同角色的人員的協(xié)作，他們通過某種過程，應(yīng)用某些技術(shù)，相互配合，共同完成一個解決方案。一個采用傳統(tǒng)設(shè)計過程的大型系統(tǒng)涉及的角色通常有：

　　1.架構(gòu)師:一個人或者一個團隊，負責(zé)將系統(tǒng)分解成子系統(tǒng)和模塊，去頂它們之間的關(guān)系（開發(fā)期、運行期）并制定相關(guān)的技術(shù)決策，如部署、開發(fā)、性能等。

　　2.高級程序員（設(shè)計師）：負責(zé)完成一個或多個子系統(tǒng)、模塊的概要設(shè)計。

　　3.程序員：負責(zé)詳細設(shè)計。

　　4.項目經(jīng)理：負責(zé)整個活動的任務(wù)協(xié)調(diào)，并根據(jù)架構(gòu)安排開發(fā)任務(wù)。

　　其中，架構(gòu)師是核心，其工作成果是后續(xù)管理和實現(xiàn)的基石。有什么樣的架構(gòu)，便會有什么樣的開發(fā)組織結(jié)構(gòu)。如分層架構(gòu)，必然會存在界面、業(yè)務(wù)、持久化及公共模塊的開發(fā)職責(zé)分配，由不同人（團隊）完成不同層的工作。

     現(xiàn)代軟件，因為規(guī)模和復(fù)雜性，再也無法由個人獨立完成所有工作，必須依靠協(xié)作。協(xié)作首先需要分工，明確各工種的職責(zé)，個人依照職責(zé)行事。分工之后便有了工作的先后次序，不同次序的串聯(lián)需要一定規(guī)則，便形成了一些過程規(guī)范，大家依照規(guī)范協(xié)同。所以，才有了那么多的軟件工程方法論，開發(fā)才有了架構(gòu)師，設(shè)計師和程序員的細分。不能簡單的認(rèn)為架構(gòu)師>設(shè)計師>程序員，他們主要的區(qū)別在于工作范圍的廣度和深度的側(cè)重點不同。架構(gòu)師更廣，程序員工作的更深入。

     為了使用一致的思維考慮問題與問題的解決方法，誕生了OOP。為了分離業(yè)務(wù)與支持服務(wù)，讓不同的人在不同的時間和地方分別解決不同問題，誕生了AOP。為了便于開發(fā)人員與用戶達成待解決問題的一致認(rèn)識，誕生了DDD。

     設(shè)計時無論采用何種種過程、技術(shù)和人員組織方式，根本目的只有一個：給出關(guān)于需求的技術(shù)解決方案。

     實際工作中還會碰到一個嚴(yán)重的問題，常常發(fā)現(xiàn)，要解決的問題，并不是地上的石頭，靜靜的躺在那兒，等你照劍譜揮劍的。經(jīng)常是，哦，我要砍的不是這塊，是那塊，甚至不是碎石而是需要劈柴，一身武藝無處使。不由怒從心頭，不時問候需求人員或者客戶，干嘛不一次說清楚，寫的仔細點。害我改這改那兒的。對此，Brooks在《設(shè)計原本》說：設(shè)計的本質(zhì)是幫助客戶發(fā)現(xiàn)他們想要的需求。

　　設(shè)計的本質(zhì)！

     根本上，解決方案和問題是共同變化的，甚至?xí)嗷ビ绊憽，F(xiàn)實中，需求階段給出的需求，往往是初始需求，隨設(shè)計過程的推進，它會奇妙的發(fā)生一些變化：

　　1.需求描述更精確了：隨著設(shè)計深入，發(fā)現(xiàn)原來的描述存在模糊的方，需要更精確才能做出設(shè)計決策。

　　2.需求描述錯了：設(shè)計著，突然，卡住了，一交流，發(fā)現(xiàn)，哦原來這不是用戶要的，他們要那樣的，其實很簡單。

　　3.出現(xiàn)新需求：會發(fā)現(xiàn)之前不曾注意的需求，會加入系統(tǒng)性的需求，如緩存等。

     設(shè)計必須能適應(yīng)這些變化，有些需要通過技術(shù)方法，柔性的容納新變化，將變化點抽象成接口，隔離變化，新需求只要設(shè)計成新的實現(xiàn)了即可。有些則只能通過總體過程來適應(yīng)，如敏捷過程的高迭代，分批交付，在每個迭代間能響應(yīng)變化。企圖一次就做出美妙的設(shè)計是不現(xiàn)實的，設(shè)計必須具備響應(yīng)變化的能力。因此，設(shè)計人員需要：

1. KISS：時刻注意保持簡單性，簡單的方法往往也是最正確高效的。
2. 關(guān)注需求：時刻注意什么是真正的需求，遇到困難，不妨先想想，真的需要解決這個問題嗎，能換種方式嗎？
3. 適度的遠見：預(yù)見同類需求發(fā)生的可能性，并提前考慮對策。如看到報表需要導(dǎo)出成excel，想想是否有生成pdf的可能性，如有必要盡早隔離這種變化。
4. 系統(tǒng)性思維：時刻注意用需求去驗證設(shè)計，確認(rèn)設(shè)計是否滿足需求，滿足的是否牽強，是否因假想了需求而增加了額外的復(fù)雜性。
5. 全局性思維：思考設(shè)計會對開發(fā)、測試和部署運營造成什么樣的影響，因為這些方面往往存在致命的隱含需求。
6. 提升抽象層次：從一次一個系統(tǒng)轉(zhuǎn)換到一次一個系統(tǒng)族，考慮所有同類系統(tǒng)的共性和可變性，將共性做成框架，可變性提煉成配置，DSL留到具體項目實施時完成。

it知識庫：研發(fā)的那些事2—設(shè)計之惑，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。