程序員你為什麼這麼累續：編碼習慣之配置規範

請先仔細閱讀：分享我工作中制定配置文件的習慣

工作中少不了要制定各種各樣的配置文件，這裡和大家分享一下工作中我是如何制定配置文件的，這是個人習慣，結合強大的spring，效果很不錯。

=============================需求==========================

如我們現在有一個這樣的配置需求，頂層是Server，有port和shutdown2個屬性，包含一個service集合，service對象有name一個屬性，並包含一個connector集合，connector對象有port和protocol2個屬性。

我一上來不會去考慮是用xml還是json還是資料庫配置，我會第一步寫好對應的配置bean。如上面的需求，就寫3個bean。bean和bean之間的包含關係要體現出來。（使用了lombok）

然後找一個地方先用代碼產生這個bean：

然後先測試，看看是否ok。為了演示，我就直接在controller裡面調用一下

測試一下，工作正常

然後進行業務代碼編寫，等到所有功能測試完畢，就是【開發後期】，再來定義配置文件。中途當然少不了修改格式，欄位等各種修改，對於我們來說只是修改bean定義，so easy。

都ok了，再決定使用哪種配置文件。如果是json，我們這樣：

==============================JSON===========================

把上面介面調用的json複製下來，報存到配置文件。

json內容

然後修改config的bean生成的代碼為：

代碼太簡潔了，有沒有？！

=========XML=========

如果使用XML，麻煩一點，我這裡使用XStream序列化和反序列化xml。

首先在bean上增加相關註解

然後修改產品文件的bean代碼如下：

XMLConfig工具類相關代碼：

XStream庫需要增加以下依賴：

所以個人愛好，格式推薦json格式配置。

==========編碼習慣==========

配置文件編碼禁忌：

1. 讀取配置的代碼和業務代碼耦合在一起！大忌！千萬千萬不要！

如下，業務代碼裡面出現了json的配置代碼。

2. 開發初期就定配置文件

毫無意義，還導致頻繁改動！先定義bean，改bean簡單多了。我的習慣是轉測試前一天才生成配置文件。

=======重要=======

最主要的思想是，不要直接和配置文件發生關係，一定要有第三者（這裡是配置的bean）。你可以說是中間件，中介都行。 否則，一開始說用xml配置，後面說用json配置，再後面說配置放資料庫？這算不算需求變更？你們說算不算？算嗎？不算嗎？何必這麼認真呢？只是1,2行代碼的問題，這裡使用xml還是json，代碼修改量是2行。而且改了測試的話，寫個main函數或者junit測試即可，不需要測試業務，工程都不用起，你自己算算節約多少時間。

另外，代碼裡面是使用spring的習慣，沒有spring也是一樣的，或者配置的bean你不用spring注入，而用工具類獲取也是一樣，區別不大。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！