Windows應用軟件開發，會有很多常用的模塊，比如數據庫、配置文件、日志、后臺通信、進程通信、埋點、瀏覽器等等。下面是目前我們公司windows梳理的部分組件，梳理出來方便大家了解組件概念以及依賴關系：

業務/通用組件：通用模塊，流程/邏輯基本是固定不變的，變的部分是上層業務調用，所以不變的部分我們需要把它固化下來、穩定下來，減少代碼的復用、提高共性代碼的穩定性、提升項目/人員的開發效率。

框架組件：除了通用模塊，還有一些流程比較復雜。比如軟件啟動時很多業務的處理，需要框架來梳理、組織好業務流程，使其業務模塊分層合理、依賴關系清晰。

所以我們抽取/開發了一些組件，以后還會有更多的組件。組件的開發/維護，大家都會參與，所以需要同步一些如何做好、做穩的概念。

組件調用方

組件尤其是通用組件，我們能支持更多方向的，一定要提供好支持。站在其它開發人員，考慮更多應用、業務的使用及場景，有這些思維，會讓你的組件設計更加完善、可用性更高。

• 開發人員 - 自己、其它開發小伙伴、外部第三方開發人員
• 各個應用軟件 - 內部軟件、ISV以及ODC軟件
• 業務場景 - 會議、醫療、教育等

組件設計原則

組件是應用軟件開發的基石，組件不穩定，應用不可能穩定下來。所以我們需要考慮怎么做好組件。

如何把組件設計好，怎么評估組件的好壞？組件設計評估，有哪些維度

結合我的工作經驗，吸收到的知識點，以下是我個人的一些總結：

1.所見即所得

“所思即所見，所見即所得”，這是佛學里的思維。

我們軟件設計也有這個“所見即所得”的原則，看見什么就是什么，執行的邏輯就是看到的方法/協議名稱。

組件、接口及方法，應該是只做名稱對應的實現。不得包含未知的邏輯，比如接口里同時存在Get、Check，在Get方法內調用了Check。又比如執行元素的縮放，縮放方法中不應該存在旋轉邏輯如設置角度。

也不得只實現部分邏輯，比如清空用戶緩存，結果內容只執行了部分路徑下的數據清空。

所見即所得，關鍵點是：

• 對外的定義，要符合業務的第一性原理，回到組件設計的初衷，該有的功能/邏輯一個也不能少。
• 內部的邏輯，圍繞著協議名稱去實現，要覆蓋且不脫離原有的初衷。

另外，solid中的單一職責原則，也是“所見即所得”原則中的一部分概念，設計要清晰、單一。

2.簡單

簡單，意思是對外要簡潔、單一。所有的組件，都是給自己以及其它開發人員使用的，給各個應用調用的，那我們就需要考慮使用成本以及學習成本。

調用組件時，能夠以最快的速度理解接口/組件的使用，以最快的速度完成組件的調用，這是組件開發人員需要考慮的。如果給出的接口以及調用流程太過復雜、混亂，調用時不得不花很多時間溝通、理解如何調用；項目上也會因為調用流程復雜，導致業務邏輯復雜，降低后續的可維護性、提高BUG定位的復雜性。

所以我們設計組件/接口，需要：

• 盡量少暴露內部實現。
  • 不需要開放的類要隱藏
  • 外界不需要關心的屬性要設置internal
  • 外界用不到的方法，設置internal。或者刪除對外暴露接口里的冗余方法
• 實現要簡單
  • 對外暴露的接口/方法，盡可能的減少數量，能合并的合并
  • 對外暴露的接口/方法，盡可能的減少參數，以最少參數實現相應功能

用一句話總結，就是最少知識原則（迪米特原則）

對外暴露越少越好，暴露的少肯定能減少耦合。我們常提的封裝就是這個意思，高內聚低耦合，內部實現復雜的邏輯，外部減少耦合。

3.完整

完整是指組件，要提供一整套完整的功能，能全部覆蓋對應場景，不能開發一部分然后提供出去使用。

• 盡可能的將應用內與這個組件相關的通用代碼，挪到組件內
• 盡可能的滿足后續業務的需要。不管是新增需求、新增應用、新增場景，后續都應該盡量無需新增代碼，即可滿足業務需求

比如，我們做OTA組件，那你應該把升級的所有實現放在OTA組件里。一個組件做一類的事情，但這個組件一定要把這一類的事情做完整。完整的意思是，在應用使用OTA組件時，能通過組件完成所有OTA的相關操作。比如檢驗是否需要升級，這段邏輯如果放在應用層去做，那就會存在冗余的重復代碼，說明OTA組件未設計完整、沒有實現完整。

當然如果你這樣實現內部代碼過多，那可以拆分一些獨立的組件，如雙網卡可以拆分為雙網卡使用組件、雙網卡修復組件。

完整，意味著可用性高，這一類場景的組件能支撐更多的業務。

4.易維護

易維護指的是，組件內部的代碼實現以及設計應該容易維護。開發通用組件，后續可能會有BUG，如何保證定位問題、解決問題的高效呢？那就需要內部清真的代碼實現、清晰的代碼設計。如果一堆不安全代碼、實現流程復雜、依賴關系混亂，肯定很難定位問題根因，修改代碼后容易牽一發動全身，如果是后面的開發人員，估計他會吐N多口水。更不用說業務組件了，業務組件如果內部不易維護，BUG肯定一堆又一堆。

如何提升代碼的可維護性？可以從以下幾個方面著手：

• 代碼實現要簡潔
• 類、函數名稱，要簡單、易理解
• 類與類、模塊與模塊的關系要盡量簡單，保持線性原則，模塊分層合理

一般來說，只要你的代碼易讀易理解，可維護性不會差到哪里去。擁有結構化思維，代碼的流程肯定不會亂。

可維護性還有很多要考慮的，就比如我們大部分組件內部也需要考慮擴展性、復用性。把可變的部分設計成抽象類或者接口暴露給上層，由業務注入變化/擴展的實體；把一些不變的部分抽成工具類或者基類，通過靜態或者組合來調用，減少內部依賴。

更深的，那就需要熟練掌握設計原則、設計思想、編程范式、架構思維，利用你的重構意識、抽象意識、封裝意識、甚至“潔癖”意識，創造優秀的代碼。

5.穩定

穩定性，包括性能以及質量。代碼穩定，是衡量組件的一個重要指標，是一個狀態。

組件不穩定，內部實現臟、亂、差，會體現到應用軟件的BUG上。

設計要素不是獨立的，而是有些有關聯的。比如組件易維護，組件穩定性一般不會差到哪去。提升了穩定性，代碼的可用性也會提升；