[TOC] ## 程序組織 維護"設計的緣由"與維護"設計本身"一樣重要 架構應該定義程序的主要構造塊(building blocks),根據程序規模不同,哥哥構造塊可能是單個類,也可能是由許多類組成的一個子系統 ## 主要的類 架構應該詳細定義所用的主要的類 它應該住處每個主要類的責任 ,以及該類如何與其他類交互. 它應該包含對類的繼承體系,狀態轉換,對象持久化等 架構應該記訴曾經考慮過的其他類的設計方案,并給出選用當前的組織架構的理由,架構無須說明系統中的每個類. 瞄準80/20 法則,對系統構成系統的80%的行為20%的類進行詳細說明 ## 數據設計 架構應該描述所用的主要文件和數據表的設計, 數據通常只應該有一個子系統或一個類直接訪問:例外的情況就是通過訪問器,或訪問器子程序--以受控且抽象的方式來訪問數據, ## 業務規則 架構依賴于特定的業務規則,那么它就應該詳細秒速這些規則,病描述這些規則對系統設計的影響 ## 用戶界面設計 用戶界面常常在需求階段進行詳細說明. 架構應該模塊化,以便在替換為新用戶界面時不影響業務規則和程序的輸出部門 例如: 架構應該使用我們很容易地做到:砍掉交互式界面的類,插入一組命令行的類 ## 資源管理 架構應該描述一份管理稀缺資源的計劃 稀缺資源包括: 數據庫連接,線程句柄等, 在內存受限的應用領域,如驅動程序和嵌入系統中,內存管理是架構應該認真對待的另一個重要領域 架構應該估算在正常情況和極端情況下的資源使用量 ## 安全性 描述實現設計層面和代碼層面的安全性的方法 在架構階段接力威脅模型,在孩子定編碼規范的時候應該把安全性牢記在心,包括處理緩存區的方法,處理非受信數據(用戶輸入的數據,cookies,配置數據(文件),和其他外部接口輸入的數據)的規則,加密,錯誤消息的細致程度,保護內存中的秘密數據,以及其他事項 ## 性能 性能目標可以包括資源的使用,定義資源(速度,內存,成本)之間的優先順序 如果為了滿足性能目標,需要在某些部門使用特定的算法或數據類型,架構在應該說清楚,架構中也可以各個類或各個對象的空間和時間的預算 ## 可伸縮性 是指系統增長以滿足未來需求的能力 架構應該描述系統如何應對用戶數量,服務器數量,網絡節點數量,數據庫記錄數,數據庫記錄的長度,交易量等的增長 ## 互用性 如果預計這個系統與其他軟件或硬件共享數據庫或資源,架構應該描述如何完成這一任務 ## 國際化 / 本地化 國際化常常成為"I18n",因為國際化的英文單詞"Internationalization", 因為首尾兩個字符"I"和"N"之間一共有18個字母 本地化成為"L10n"(Localization) 大多數交互系統包含幾十上百條提示,狀態顯示,幫助信息,錯誤信息,等等.還應該表現出考慮典型的字符串問題和字符集問題,包括所用的字符集(ASCII,DBCS,EBCDIC,MDCS,Unicode,ISO 8859), 架構可以決定,在需要的時候,是在代碼中直接嵌入字符串,還是將這些字符串封裝入某個類,并通過類的接口來使用它, ## 輸入輸出 架構應該詳細定義讀取策略(reading scheme)是先做(look-achcad),后做(look-bechind) 還是即時做(just-in-time) 而且應該描述在哪里航檢測I/O錯誤:在字段,記錄,流,或者文件的層次 ## 錯誤處理 錯誤處理已被證實為現代計算機科學, 估計程序中高達90%用來處理異常情況,進行錯誤處理,或做薄記,,所以需要一種"一致的處理錯誤"的策略 錯誤處理常備視為"代碼約定層次/coding-convention-level"的事情 要考慮的問題: 1. 錯誤處理是進行糾正還是僅僅進行檢測.如果是糾正,程序可以嘗試從錯誤中恢復過來,如果是檢測,那么程序可以像"沒有發生任何事"一樣繼續運行,也可以退出 2. 錯誤檢測是主動還是被動的.系統可以主動的預測錯誤(如:通過檢測用戶輸入的有效性,也可以在不能避免錯誤的時候,被動的相應錯誤) 3. 程序如何傳播錯誤,可以立即丟棄引發該錯誤的數據,也可以把這個錯誤當成一個錯誤,并進入處理狀態,或者可以等到所有處理完成,在通知用戶說在某個地方發現了錯誤 4. 錯誤消息的處理有什么約定,架構要定義一致的錯誤策略 5. 如何處理異常(exceptions),架構應該規定代碼合適能拋出異常,在什么地方捕獲異常,如何記錄log這些異常, 在程序中,在什么乘次上處理錯誤,可以在發現錯誤的地方處理,可以將錯誤傳遞到專門處理的類進行處理,或者沿著函數調用鏈往上傳遞錯誤. ## 容錯性 架構還應該詳細定義所期望的容錯種類 容錯是增強系統可靠性的一組技術,包括檢測錯誤,如果可能的話從錯誤中恢復,如果不能從錯誤中的恢復,則包容其實不影響 舉例: 1. 系統在檢測到錯誤的時候退回去,在試一次,如果第一次的結果是錯誤的,那么系統可以退回到之前一切正常的時刻,然后從該點繼續運行 2. 系統有用一套輔助代碼,以備在主代碼出錯的錯誤使用,本例中,如果發現第一次的答案似乎有錯,系統就切換到另一個計算平方根的子程序,以取而代之 3. 系統可以有一種表決算法,它可以有三個計算平方根,每一個都使用不同的計算方法,每個類分別計算平方根,然后系統對結果進行比較,根據系統內建的容錯機制的種類系統可以以三個結果的均值,中值,或眾數作為最終結果 4. 系統使用某個不會對系統其余部分產生部分產生畏寒的虛假值(phoney value)代替這個錯誤的值 其他容錯的方法包括,再遇到錯誤的時候,讓系統轉入某種"部分運轉/partail operation"的狀態,或轉入某種"功能退化/degrader functionaity" 系統可以自動關閉或重啟, ## 架構的可行性 架構應該論證系統的技術可行性。 如果在任何一個方面不可行都會導致項目無法實施,那么架構應該說明“這些問題是如何經過研究的”—通過驗證概念的原型( proof-of-conceptprototype)、研究、或其他手段。必須在全面開展構建之前解決掉這些風險。 ## 過度工程 健壯性(robustness)是指"系統在檢測到錯誤后繼續進行"的能力,如果組成系統的各個部門都只能在最低限度上滿足健壯性要求,name系統整體上達不到所要求的的健壯程度的. 在軟件中,鏈條的強度不是取決于最薄弱的一環,而是等于所有薄弱環節的乘積. 架構應該清楚的指出程序員應該為了"為了謹慎起見寧可進行過度的工程(overengineering)",還是應該做出最簡單的能工作的東西. 詳細定義過度工程(裕度工程)的方法尤其重要,因為許多程序員出于專業自豪感,對自己編寫的類過度工程 ## 關于復用的決策 如果開發計劃提倡使用業已存在的軟件、測試用例、數據格式或其他原料架構應該說明:如何對復用的軟件進行加工,使之符合其他架構目標——如果需要使之符合的話。 ## 變更策略 構建軟件產品是一個學習的過程. 架構應該清楚的秒速處理變更的策略,并說明"最有可能增強的功能同樣也是最容易實現的" 架構應該指出"延遲提交/delay commitment"所用的策略,比如說,架構也許規定使用表驅動(而不使用編碼的if 語句),它也許還規定"表"中的數據是保存在外部文件中,而非直接寫在程序代碼中,這樣就能做到在不重新編譯的下修改程序 ## 架構的總體質量 架構應該是帶有少許特別附加物的精煉且完整的概念體系 大型系統的本質問題是維持其概念完整性 架構的目標應該清楚的表達,以系統的可更改性(modifiability)為首要目標設計與以性能方面絕不妥協為首要目標的設計肯定是不同的--即便兩個系統的功能完全一樣 優秀的軟件架構很大程度上是與機器和編程語言無關的,要盡可能地獨立于環境 這樣你就能抵抗對系統進行過度的架構的誘惑,也避免提前去做那些放到架構設計起見能做到更好的工作 架構應該在對系統"欠描述/underspecifying"和"過度描述/oversoecifying"之間的那條分界線.