Windows應用軟體開發，會有很多常用的模組，比如資料庫、配置檔案、日誌、後臺通訊、程序通訊、埋點、瀏覽器等等。下面是目前我們公司windows梳理的部分元件，梳理出來方便大家瞭解元件概念以及依賴關係：
每個應用裡，現在或者以後都可能會存在這些模組。以我團隊開發的全家桶為例，十多個應用對後臺訪問，就會有十多個重複的模組。後臺通訊的設計、開發、BUG修復，都是重複工作量。
業務/通用元件：通用模組，流程/邏輯基本是固定不變的，變的部分是上層業務呼叫，所以不變的部分我們需要把它固化下來、穩定下來，減少程式碼的複用、提高共性程式碼的穩定性、提升專案/人員的開發效率。
框架元件：除了通用模組，還有一些流程比較複雜。比如軟體啟動時很多業務的處理，需要框架來梳理、組織好業務流程，使其業務模組分層合理、依賴關係清晰。
所以我們抽取/開發了一些元件，以後還會有更多的元件。元件的開發/維護，大家都會參與，所以需要同步一些如何做好、做穩的概念。
元件呼叫方
元件尤其是通用元件，我們能支援更多方向的，一定要提供好支援。站在其它開發人員，考慮更多應用、業務的使用及場景，有這些思維，會讓你的元件設計更加完善、可用性更高。
- 開發人員 - 自己、其它開發小夥伴、外部第三方開發人員
- 各個應用軟體 - 內部軟體、ISV以及ODC軟體
- 業務場景 - 會議、醫療、教育等
元件設計原則
元件是應用軟體開發的基石，元件不穩定，應用不可能穩定下來。所以我們需要考慮怎麼做好元件。
如何把元件設計好，怎麼評估元件的好壞？元件設計評估，有哪些維度
結合我的工作經驗，吸收到的知識點，以下是我個人的一些總結：
1.所見即所得
“所思即所見，所見即所得”，這是佛學裡的思維。
我們軟體設計也有這個“所見即所得”的原則，看見什麼就是什麼，執行的邏輯就是看到的方法/協議名稱。
元件、介面及方法，應該是隻做名稱對應的實現。不得包含未知的邏輯，比如介面裡同時存在Get、Check，在Get方法內呼叫了Check。又比如執行元素的縮放，縮放方法中不應該存在旋轉邏輯如設定角度。
也不得只實現部分邏輯，比如清空使用者快取，結果內容只執行了部分路徑下的資料清空。
所見即所得，關鍵點是：
- 對外的定義，要符合業務的第一性原理，回到元件設計的初衷，該有的功能/邏輯一個也不能少。
- 內部的邏輯，圍繞著協議名稱去實現，要覆蓋且不脫離原有的初衷。
2.簡單
簡單，意思是對外要簡潔、單一。所有的元件，都是給自己以及其它開發人員使用的，給各個應用呼叫的，那我們就需要考慮使用成本以及學習成本。
呼叫元件時，能夠以最快的速度理解介面/元件的使用，以最快的速度完成元件的呼叫，這是元件開發人員需要考慮的。如果給出的介面以及呼叫流程太過複雜、混亂，呼叫時不得不花很多時間溝通、理解如何呼叫；專案上也會因為呼叫流程複雜，導致業務邏輯複雜，降低後續的可維護性、提高BUG定位的複雜性。
所以我們設計元件/介面，需要：
-
儘量少暴露內部實現。
- 不需要開放的類要隱藏
- 外界不需要關心的屬性要設定internal
- 外界用不到的方法，設定internal。或者刪除對外暴露介面裡的冗餘方法
-
實現要簡單
- 對外暴露的介面/方法，儘可能的減少數量，能合併的合併
- 對外暴露的介面/方法，儘可能的減少引數，以最少引數實現相應功能
用一句話總結，就是最少知識原則（迪米特原則）
對外暴露越少越好，暴露的少肯定能減少耦合。我們常提的封裝就是這個意思，高內聚低耦合，內部實現複雜的邏輯，外部減少耦合。
3.完整
完整是指元件，要提供一整套完整的功能，能全部覆蓋對應場景，不能開發一部分然後提供出去使用。
- 儘可能的將應用內與這個元件相關的通用程式碼，挪到元件內
- 儘可能的滿足後續業務的需要。不管是新增需求、新增應用、新增場景，後續都應該儘量無需新增程式碼，即可滿足業務需求
比如，我們做OTA元件，那你應該把升級的所有實現放在OTA元件裡。一個元件做一類的事情，但這個元件一定要把這一類的事情做完整。完整的意思是，在應用使用OTA元件時，能透過元件完成所有O他的相關操作。比如檢驗是否需要升級，這段邏輯如果放在應用層去做，那就會存在冗餘的重複程式碼，說明OTA元件未設計完整、沒有實現完整。
當然如果你這樣實現內部實現過多，那可以拆分一些獨立的元件，如雙網路卡可以拆分為雙網路卡使用元件、雙網路卡修復元件。
完整，意味著可用性高，這一類場景的元件能支撐更多的業務。
4.易維護
易維護指的是，元件內部的程式碼實現以及設計應該容易維護。開發通用元件，後續可能會有BUG，如何保證定位問題、解決問題的高效呢？那就需要內部清真的程式碼實現、清晰的程式碼設計。如果一堆不安全程式碼、實現流程複雜、依賴關係混亂，肯定很難定位問題根因，修改程式碼後容易牽一髮動全身，如果是後面的開發人員，估計他會吐N多口水。更不用說業務元件了，業務元件如果內部不易維護，BUG肯定一堆又一堆。
如何提升程式碼的可維護性？可以從以下幾個方面著手：
- 程式碼實現要簡潔
- 類、函式名稱，要簡單、易理解
- 類與類、模組與模組的關係要儘量簡單，保持線性原則，模組分層合理
一般來說，只要你的程式碼易讀易理解，可維護性不會差到哪裡去。擁有結構化思維，程式碼的流程肯定不會亂。
可維護性還有很多要考慮的，就比如我們大部分元件內部也需要考慮擴充套件性、複用性。把可變的部分設計成抽象類或者介面暴露給上層，由業務注入變化/擴充套件的實體；把一些不變的部分抽成工具類或者基類，透過靜態或者組合來呼叫，減少內部依賴。
更深的，那就需要熟練掌握設計原則、設計思想、程式設計正規化、架構思維，利用你的重構意識、抽象意識、封裝意識、甚至“潔癖”意識，創造優秀的程式碼。
5.穩定
穩定性，包括效能以及質量。程式碼穩定，是衡量元件的一個重要指標，是一個狀態。
元件不穩定，內部實現髒、亂、差，會體現到應用軟體的BUG上。
設計要素不是獨立的，而是有些有關聯的。比如元件易維護，元件穩定性一般不會差到哪去。提升了穩定性，程式碼的可用性也會提升；