我想说其实你很好，你自己却不知道 － 《暖暖》
你根本不需担心这世间怎想你，其实我说你已经够完美 － 《任何天气》
昨晚上突然想去查一下，.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的的饭碗了。
不过那时我可能就转行了，给大企业作咨询，领先别人一步才能赚得更多嘛。