能否跟配置文件完全說88

我想說其實你很好，你本身殊不知道 － 《暖暖》

你根本不需擔憂這世間怎想你，其實我說你已經夠完美 － 《任何天氣》

昨晚上忽然想去查一下，.NET與Java的職位比，大約是1：2。聽說學.NET和Java的比值是1：3，因此初學.NET好找工做，.NET仍是中小公司用得多，多數大公司都招但比Java少得多。這仍是編程語言優點在大公司業務中比重太小致使的。

不過Windows外的.NET已經發展起來了，驚訝地發現Ubuntu上代碼C#比重竟然最高，將來大有可期。

也翻到了一些談.NET程序員工資的見解，我之前一直以爲這些討論很無聊，無非是付出多少獲得多少。不過如今從宏觀看，確實.NET的低薪職位比例要高很多，這些職位的程序員，雖然他們沒有太多夢想，缺少創造性就像建築工同樣，但社會須要他們，也應該給他們尊重。每一個人選擇的活法不一樣，薪水不等於成功，更不等於快樂。不過你要是抱怨本身工資低，非要怪.NET，仍是本身努力吧。

 

好了，再也不廢話進入正題。.NET代碼通常都屬於某個Project，Project屬於某個Solution，分別對應proj和sln文件，每一個project下面還有config文件。有些框架還有本身專門的配置文件，好比NHibernate。這種XML配置文件，C++和Java也同樣，我不知道這是從什麼年代興起的，歷來也天然而然的接受了，今天卻忽然看起來很礙眼。竟然想到了，爲何咱們不能把它們去掉？

我是怎麼產生這種想法的呢？首先是對編程的認識，編程工做其實有兩部分寫代碼和管理配置。另外一個緣由是對Java的接觸，瞭解到Java上手比.NET難，由於一樣的工做，須要多做不少配置。因此MVC有個說法，約定勝於配置，配置這東西越少越好。

去年使用EF的FluentAPI時，感受用這個加T4模板，能夠有效地兼容現有項目實體，能夠輕鬆應對擴展，「配置」起來也很舒服，這些優點是XML配置文件不具有的。

舉個例子，下面這個最簡單的HelloWorld項目csproj文件中，編譯的片段：

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>

 

首先裏面大部分東西都是默認值，既然是默認值，爲何還要放到裏面而不是做爲約定？默認狀況雖然沒問題，可是一旦你想作個Customization，好比想改變一下bin輸出路徑，你是願意先Unload Project，再Edit Project，修改 OutPath屬性（要分清debug/release），再reload呢？仍是寫像下面的代碼：

public class HelloWorldProject : ConsoleAppProject{
protected override void OnInit()
    {        
        this.Configurations["Release"].OutputPath = "bin\" + DateTime.Now.ToShortDateString(); 
    }
}

 

哈哈，動態的編譯路徑，配置文件你難辦了吧？很多人說，能夠用build event，說到這個，是我最想吐槽的了，好比這段東西：

<PropertyGroup>
  <PostBuildEvent>copy /Y $(TargetDir)$(TargetName).*  $(SolutionDir)App\Bin\</PostBuildEvent>
</PropertyGroup>

 

copy命令有點Linux和Java的帶感，$TargetName，還有參數/Y是什麼意思，記住這種東西只是咱們頭腦中的負擔。並且動態路徑仍是很麻煩，實現更復雜邏輯，少不了還要算定義一個target。VS如今雖然說支持項目文件嵌入代碼了，但又何須，爲何不直接提供擴展類呢：

public class HelloWorldProject : ConsoleAppProject
{
    protected override void OnPostBuild()
    {
        foreach (var filename in Directory.GetFiles(base.TargetDirectory))
        {
            File.Copy(filename, this.SolutionDirectory + "App/bin" + Path.GetFileName(filename));
        }
    }
}

 

如今基於各類項目的自動化部署方案不少，那些須要不少配置的方案都是浮雲。每一個項目業務都不一樣，部署方案也不一樣，對於大中型項目，從長遠角度只有本身寫程序自動打包部署，才最省時間最高效率的方式。

 

配置的本義，是爲了靈活地應付變化。既然已經有更靈活的面向對象方案，那不少枯燥地配置工做就能夠轉化爲寫代碼，能夠思考重用和優化。如今程序員工做一個問題就是配置工做過多，有時候一個框架搞得全是配置，好比SharePoint，配置真心強大。可到最後呢，該擴展的功能仍是得寫代碼，原來的配置還得維護，實在痛苦。配置過多對框架或產品的普及的危害，這已經被普遍認識到了，好比WCF剛發佈時，搞得config文件又臭又長，WCF4.0作了大幅改進，要配置的東西變得不多，甚至只須要一個地址就夠了。

項目的config文件仍是有用的，可是應該只存最簡單形式的東西，好比鏈接字符串、地址、用戶名。通除了咱們，對不接觸代碼的系統管理員也能夠看懂。好比一個網站，能夠定義一個統計請求的Module，須要統計時，管理員把它加到在配置文件裏，過了段時間咱們不須要了，註釋掉就好了。這種業務配置有其存在價值。

過複雜的配置節，雖然可以動態改變程序行爲，可這種狀況實在罕見，好比修改表的列名。比起配置帶來的負擔，得不償失。

至於那些編譯配置的文件，好比項目proj文件，基本能夠被面向對象代碼取代。管理員不會跟這些打交道。若是咱們把用於多數配置的精力，轉移到優化重用代碼上，對項目對自身是共贏的結果。

總之，儘管代碼不能解決一切問題，好的程序員應該用代碼解決儘量多的問題。

 

結尾，思路又回到開始，想，若是.NET程序員都努力起來會怎麼樣？那咱們是否是要擔憂工資被拉低了呢。杞人憂天而已，NET開發更給力了，確定應用得更廣，職位就更多了。好比，MarketPlace應用數量質量很快就會遇上AppStore和GooglePlay，哈哈，那樣反而要擔憂別Java的的飯碗了。

不過那時我可能就轉行了，給大企業做諮詢，領先別人一步才能賺得更多嘛。