《編程匠藝》之軟件的架構與改良

時間 2019-11-09

標籤編程匠藝軟件架構改良欄目系統架構简体版

原文原文鏈接

第三部分: 代碼的造成過程(軟件的架構)

1. 崇尚設計(如何作良好的軟件設計)

軟件設計的層次
- 系統體系結構(總體系統和子系統,以及子系統之間的鏈接方式)
- 模塊於組件
- 類和數據類型
- 函數
設計良好的特徵
- 簡潔和優雅
- 模塊化(高內聚,低耦合)
- 良好的接口(爲了建立良好的接口,能夠遵循下面的步驟:)
  - 肯定客戶端, 瞭解它的需求
  - 肯定供應端, 瞭解它的能力
  - 推斷所需的接口類型(函數, 類, 網絡協議?)
  - 肯定操做的性質(究竟須要提供什麼樣的功能?)
- 可擴展性(須要仔細評估如今的功能, 之後可能有的功能, 之後必定會有的功能)
- 避免重複
- 可移植性(儘可能減小對特定平臺的依賴; 能夠添加一個平臺抽象層來屏蔽差別)
- 良好的文檔(主要針對頂層的設計;在代碼層面實現自說明)
如何作好的設計?
- 設計方法和過程
  - 結構化設計(以分治做爲主要特徵,把問題不斷分解爲更小的問題)
  - 面向對象的設計(面向對象的焦點在於系統中的數據,結構化設計焦點在於系統執行的操做; 能夠花點時間看看設計模式)
- 設計工具
  - UML
  - 設計模式
  - 流程圖
  - 僞代碼
  - CASE工具
你如何衡量一段代碼的設計質量?
- 設計是很難量化的, 只是對設計的審美評價.判斷設計質量的惟一途徑就是閱讀代碼.

2. 軟件的體系結構(奠基軟件設計的基礎)

什麼是軟件體系結構?
- 體系結構有時候被稱爲高層次設計.
軟件藍圖
- 藍圖的做用:
  1. 肯定軟件的模塊,庫,組件
  2. 肯定組件之間是如何通訊的
  3. 有助於鑑別和肯定系統中的接口特性,闡明子系統的角色和職責
視圖
- 在體系結構的設計中,通常會有多個系統層來看待,就如同建築有外觀圖, 佈線圖, 管道圖等.主要包含:
  1. 概念視圖,也稱邏輯視圖,顯示了系統的主要部分和他們之間的關係.
  2. 實現視圖,包含了實現模塊的角度.
  3. 進程視圖,使用任務,進程,通訊來顯示動態的結構.
  4. 部署視圖,顯示任務在分佈式系統不一樣物理節點上的分佈.
在什麼時候何處進行體系結構設計
- 體系結構是需求達成一致後的第一個開發步驟.
- 體系結構設計是獨立於模塊設計階段的,雖而後續的詳細設計可能會反過來修正體系設計.
體系結構用來作什麼?
- 驗證(能夠來整體驗證是否可行, 是否知足需求, 是否有重複的工做)
- 溝通(體系結構將問題域映射到解決域, 並指明瞭如何擴展, 應該與軟件保持一致)
- 判斷優劣(來評判是否須要開發這個東西;並標識出重要的易錯點)
體系結構最關注的是組件和鏈接.
- 組件能夠是對象,進程,數據庫或者第三方產品.每一個組件都是一個獨立的功能單元.還會有描述外部可見性的東東.
- 鏈接. 鏈接能夠是簡單的函數調用,也能夠是穿過管道的數據流.能夠是事件處理程序,也能夠是傳遞的消息機制.鏈接能夠是同步的,也能夠是異步的.
什麼是良好的體系結構?
- 一個良好的體系結構是簡潔的.是精心選擇的模塊和合理的通訊方式組成的.
- 體系結構設計須要平衡好組件的粒度.體系結構不規定各個模塊內部的工做機制.須要是儘量的高內聚,低耦合.
- 體系結構會列出已作出的設計決策,並闡明爲何比別的可選策略好.
體系結構風格
- 每種結構都有不一樣的特徵:
  - 更改數據表示法,算法和所需功能的適應能力
  - 模塊分割和鏈接的方法
  - 全面性
  - 知足性能要求的能力
  - 組件重用的考慮
常見的體系結構
- 分層的體系結構(如OSI參考模型)
- 管道和過濾器體系結構(數據流是串行的,每一個過濾器完整本身的功能,而後向下遊傳遞,缺點是錯誤處理麻煩)
- c/s體系結構(他將功能分在客戶機和服務器上兩部分)
- 基於組件的體系結構(核心就是通訊的基礎結構或者中間件)
- 框架()
常見的接口類型:
- API
- 類層次結構
- 組件技術
- 數據格式

3. 改良與革命(代碼是如何成長的)

要下面的警告信息,防止代碼開始腐爛:
- 代碼中遍及着大型的類和複雜的函數
- 函數的名稱很隱晦
- 沒有任何結構(不知道去哪裏尋找某個功能)
- 內容重複(有許多相互獨立的代碼作着相同的事)
- 高耦合性
- 在數據流過系統時,它在各類表示法之間反覆轉換
- API變得模糊不清
- 代碼中導出都是權宜之計:治標不治本的修改.系統的外圍滿是這種修改.
- 有些函數的參數太多了
- 添加新功能時,沒有提供任何支持文檔;現有的文檔過期了.
- 代碼在編譯時產生了不少告警
- 你發現註釋說:'不要動這些代碼'