硬編碼經(jīng)常被認(rèn)為反面模式。把隨著時(shí)間而變化的這些值，硬編碼到源代碼里，每當(dāng)這些值真正變化時(shí)，都需要重新編譯。

然而這個(gè)陳述也是正確的，我覺得，當(dāng)開發(fā)一個(gè)應(yīng)用程序時(shí)，硬編碼應(yīng)該成為默認(rèn)選擇。 

[[150744]]

硬編碼 VS 配置文件

當(dāng)你忙于一個(gè)項(xiàng)目或功能時(shí)，總是有一些魔法數(shù)字或字符串，它們潛在地會在將來變化。***個(gè)沖動就是讓這些變化可配置，今后你就能輕松修改它們。

對于大多數(shù)情況，這種決定使得接下來的維護(hù)復(fù)雜化。我們這里所面對的，是一個(gè)經(jīng)典的困境「簡單 VS 敏捷」。隨著應(yīng)用程序的增大，修改它的某些參數(shù)變得更加容易，因?yàn)樗鼈儽惶崛〉脚渲梦募铮瑫r(shí)總體維護(hù)負(fù)擔(dān)增加了。

在極端情況下，你或許最終得到了數(shù)十個(gè)、甚至數(shù)百個(gè)可配置的參數(shù)，這使得維護(hù)應(yīng)用程序變得極度痛苦。這種情形被叫做配置地獄（configuration hell）。

就和其它很多軟件設(shè)計(jì)決定一樣，我們需要求助于 YAGNI 原則。所有這些參數(shù)真的需要馬上可配置嗎？或者，我們只是為了提前安排好？如果屬于后者的情況，當(dāng)這個(gè)需要變得明顯之前，我們***砍掉配置文件，以保持其小巧。

如果該必要性沒有被證明，那么硬編碼就應(yīng)該是默認(rèn)選擇。對于硬編碼，我的意思不是說，你應(yīng)該把魔法數(shù)字和字符串?dāng)U散到你的項(xiàng)目源代碼里。它們?nèi)匀恍枰占⒈环旁谝粋€(gè)地方做為常量。然而，這意味著你應(yīng)該將它們從配置文件移除。

日志的例子

讓我們舉些例子，看看我們在實(shí)踐中該怎樣應(yīng)用上面提到的原則。

我喜愛的日志資源庫是 NLog。它有著相當(dāng)豐富的功能，每一項(xiàng)都可輕松配置。

下面是一個(gè)典型的 NLog 安裝的配置文件：

<nlog>
  <variable name=“logFile“ value=“C:\logs\log-${shortdate}.txt“/>
  
  <targets>
    <target name=“trace“ xsi:type=“AsyncWrapper“ queueLimit=“5000“ overflowAction=“Block“>
      <target name=“file“ xsi:type=“File“ encoding=“utf-8“
              layout=“Date: ${longdate}\r\n Level: ${level}\r\n Message: ${message}\r\n“
              fileName=“${logFile}.txt“
              archiveFileName=“${logFile}.{#####}.txt“
              archiveAboveSize=“2097152“
              maxArchiveFiles=“200“
              archiveNumbering=“Sequence“/>
    </target>
  </targets>
  
  <rules>
    <logger name=“*“ minlevel=“Warn“ writeTo=“trace“/>
  </rules>
</nlog>

盡管設(shè)置本身相當(dāng)合理，我還是想提出一個(gè)疑問：把所有這些設(shè)置放在配置文件里，真的有必要嗎？我們將要修改它們嗎？在大多數(shù)情況下，答案是不。即使你對此感到懷疑，根據(jù) YAGNI 原則，那也意味著「不」。

幸運(yùn)的是，NLog 允許我們使用其配置的 API，以在代碼里做配置。因此，除了依賴于配置文件，我們能夠輕松地將這些設(shè)置挪到源代碼里。我們仔細(xì)看下這個(gè)例子，看看我們可以除掉哪些設(shè)置。

首先，在 targets 部分，你可以看到我們?yōu)檎嬲?nbsp;target 使用了 async wrapper。我們真的想讓它可配置嗎？不，這種設(shè)置很少需要修改。好的，其它的 target 呢？它設(shè)置了很多有用的屬性，比如日志的 layout、file name、maximum log file size 等等。我們真的需要這種「不用重新配置就可修改」的機(jī)會嗎？很可能，不需要。

rules 部分呢？這部分并不像 targets 部分那樣明顯。為了觸發(fā)規(guī)則而修改 最小日志等級（minlevel）的可能性貌似可以理解，因?yàn)槲覀兓蛟S因?yàn)檎{(diào)試的原因想在運(yùn)行中修改它。然而，問題在于實(shí)踐中我們從來不會這樣做。因此，我們***也移除這個(gè)設(shè)置。

好了，我們最終還剩下什么？僅有一個(gè)設(shè)置留下了，它就是日志文件本身的路徑：

<appSettings>
  <add key=“LogFilePath“ value=“C:\logs\log-${shortdate}.txt“ />
</appSettings>

現(xiàn)在，所有其它設(shè)置被放在了源代碼里：

string layout = “Date: ${longdate}\r\n“ +
    “Level: ${level}\r\n“ +
    “Message: ${message}\r\n“;
  
var config = new LoggingConfiguration();
  
var target = new FileTarget { FileName = fileName, Layout = layout /* Other params */ };
var asyncWrapper = new AsyncTargetWrapper(target)
{
    QueueLimit = 5000,
    OverflowAction = AsyncTargetWrapperOverflowAction.Block
};
var rule = new LoggingRule(“*”, LogLevel.Error, asyncWrapper);
config.AddTarget(“asyncWrapper”, asyncWrapper);
config.LoggingRules.Add(rule);
  
LogManager.Configuration = config;

你可以看到，我們移除了整個(gè) nlog 部分，并把保留的設(shè)置挪入了appSettings 部分?，F(xiàn)在它變成了我們配置文件的普通一員。

唯一的設(shè)置就是，根據(jù)被應(yīng)用的環(huán)境，真的需要具有不同的值。我們這里做的工作，就是減少表面配置，從而使得解決方案更加可維護(hù)，代價(jià)是少了一些靈活。我堅(jiān)信這是不錯的折衷方案。

隨后，我們或許發(fā)現(xiàn)我們自己經(jīng)常修改某項(xiàng)硬編碼設(shè)置。這就發(fā)出了信號，我們找到了將其挪入配置文件的正當(dāng)理由。但截至目前，就讓硬編碼成為你的默認(rèn)選擇吧。

總結(jié)

我經(jīng)常把這個(gè)規(guī)則應(yīng)用到潛在地可被挪入配置文件的所有設(shè)置上，這有助于使得它們小而可維護(hù)。還有，我注意到，即使我偶爾需要修改某些配置，直接在源代碼里修改，已經(jīng)足夠應(yīng)付大部分情況了。

[更新]

我需要指出，本文的內(nèi)容僅適用于內(nèi)部用的軟件（in-house software）。第三方資源庫開發(fā)是不同的故事。

還有，我真的感激我在本文得到的所有反饋，想不到會引發(fā)如此多的討論。但是，不要把本文的主旨——「讓硬編碼成為你的默認(rèn)選擇」——同「讓硬編碼成 為你的唯一選擇」混為一談。如果你真的需要從代碼里提取某些值、使其可配置，你***就這樣做。我向你提倡的唯一一點(diǎn)就是自問一下，這種提取是否真的有必 要。