軟件系統中的配置文件

時間 2019-12-09

標籤軟件系統配置文件简体版

原文原文鏈接

每一個小人物的心中都有一個成爲大人物的夢想，配置文件也不例外。

當咱們仍是編程新手的時候，常常會有一些前輩告訴咱們：軟件開發中要將一些可能變更的參數放到配置文件中，這樣就能夠在不改變代碼且無需從新部署程序的狀況下改變程序行爲。html

一、軟件實踐中的配置文件

正如前輩告誡咱們的那樣，『將一些可能變更的參數放到配置文件中』，可使得程序更加靈活，適應多種業務場景。因而咱們謹遵他們的教誨，在平常的開發過程當中，將數據庫鏈接參數，日誌路徑等線上環境相關的易變值加入配置文件。的確好用，當咱們的DB想要擴容，當咱們的日誌存儲想要變動，僅需修改配置文件便可。如此好用，某一天咱們可能也會將軟件中的某一個功能特性開關移步到配置文件中。不止於此，咱們開始將更多的可變參數寫在配置文件中，已達到更高的靈活度，更有甚者將一些業務邏輯操做從代碼中挪到配置文件中。因而，某一天咱們忽然發現本身大部分的時間並非在寫代碼，而是寫配置文件。數據庫

二、每個配置文件都想成爲一個DSL

每一個工具都想發展成爲一個平臺，無獨有偶，每個配置文件都想成爲一個DSL（Domain Specific Language，領域專用語言）。編程

正如第一部分描述的那樣，起初配置文件中只是一些與代碼執行環境有關的參數配置（供系統管理員使用），到最後，隨着一些『業務行爲』也被加入到配置文件中，它則慢慢地進化成爲了一種DSL。但並非每個軟件系統都須要一套本身的DSL，也不是每個DSL都會被設計地那麼易懂與易用。有些僅僅是增長了複雜度。數據結構

有人發明了『配置文件複雜讀時鐘』的概念來描述配置文件這樣的一個發展過程，十分貼切。
編程語言

12點：全部邏輯均是寫在代碼裏，有些甚至是硬編碼 - 對應業務起步期。
3點：前輩們告訴咱們，將一些可能變更的參數放到配置文件中 - 業務發展早期
6點：需求快速變化，業務邏輯愈來愈複雜，配置文件也愈來愈複雜，引入一些條件判斷，異常處理等- 業務發展中期。
9點：有一些定製化的需求開始出現，爲了應對這種變化，配置文件開始走向大量定義軟件行爲的方向，而且與業務規則緊密耦合在一塊兒 - 業務發展頂峯期
12點：最後的最後又回到原點，因此的業務邏輯均寫在配置文件中，包括硬編碼 - 業務發展瓶頸期。

因而，軟件開發人員從面向代碼編程變成了面向配置文件編程。其實，這個時期，配置文件儼然已變成了一種編程語言。工具

那麼回過頭來想想，在業務發展過程當中，衍生出了一門配置編程語言，這有必要嘛？學習

配置文件有時候的確很好用，能夠幫助軟件開發人員快速應對一些變化。可是若是過分依賴配置文件，卻不得不提它帶來的缺陷：編碼

不通用：配置文件引入了非通用的語法、語義，這對項目項目新人來講，無疑增長了學習難度，也下降了團隊的合做效率。
調試困難：不像代碼，配置文件沒法在軟件系統發生異常時進行有效地調試，導致沒法快速定位問題，修復問題，下降了軟件系統的健壯性。
可維護性差：每一門編程語言都基本上有一套自身的通用編碼規範，並隨着開發者社區而獲得進一步的完善，而配置文件，大多數軟件系統都會定義一套本身特殊的語義。相對而言一份使用通用編程語言編寫代碼的項目比軟件自帶配置文件要更好維護。
高度耦合：配置文件就如同系統對外API，一旦對外暴露就很難收回。做爲模塊的API，應該儘量地小而窄，保持高內聚，低耦合
圖靈完備性：不少帶有『行爲』的配置文件根本不是圖靈完備的（即沒法表達出計算機的全部行爲），而基本上全部的編程語言都是圖靈完備的。

本質上：配置文件與代碼表明瞭兩種編程範式：聲明式（Declarative programming）與命令式（Imperative programming）。spa

當前，幾乎全部計算機的硬件工做都是命令式的，也幾乎全部計算機的硬件都是設計來運行機器代碼，使用命令式的風格來寫的。從這點來說，大部分場景使用代碼實現業務邏輯要優於配置文件。設計