随笔 - 106  文章 - 2  评论 - 2017  0

我想说其实你很好,你自己却不知道 - 《暖暖》

你根本不需担心这世间怎想你,其实我说你已经够完美 - 《任何天气》

昨晚上突然想去查一下,.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的的饭碗了。

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

posted on 2014-01-19 21:39  小城故事  阅读(...)  评论(...编辑  收藏