能否跟配置文件完全说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的的饭碗了。

不过那时我可能就转行了，给大企业做咨询，领先别人一步才能赚得更多嘛。