一年一度的国家公务员招考报名工作即将于今晚24点截止，之所以关注这次报考是因为我GF也是诸多考生中的一员，在帮助她报考的过程中，我有了一些想法和体会。

我不是很了解公务员职位表中对职位的要求是如何确定的，但是我看了公务员职位表后第一感觉就是专业限制太’死’，职位要求太严格。众所周知，公务员招考主要还是面向社会有工作经验的人，每年统计数字表明2/3的职位录取的是有工作经验的人。我的疑问就在于此：有工作经验的人都是毕业后从事本专业的人么？不见得，有相当多的一部分人从事的并不是自己的本专业的工作，而是选择自己更喜欢的行业。这样的人如果想报考公务员就有些难了，在数千个职位中找了半天也找不到自己合适的职位，因为职位表上写的很明确，要求某某专业。

试问一个有着5年软件开发经验的大学专业是学机械的人和一个刚从学校毕业的计算机专业的大学生同时报考一个职位，结果如何呢？前者可能根本通不过资格审查，原因很简单：这个职位需要计算机专业毕业的人。那么这个有着5年软件开发经验的社会人士真的就不如这个计算机专业毕业的学生么？我看未必。这显然导致了竞争上的不平等。哇，还没等考试呢，天枰就已经倾斜了。

也许我不是很了解公务员考试，也许公务员考试和其他的招聘有不同，但是当我们的社会，我们的教育都在强调素质教育时，在宣传不要一张文凭定终身，打破专业界限时，公务员招考就像一面镜子折射出一缕缕不和谐之光。

如果说不公平还有很多，为什么专科生不能报考，为什么有些岗位非得要硕士，硕士和本科就有很大差距么？为什么不是党员就不能报考某些与政治无关的职位？太多的为什么等待着政府去回答。’公平’这一公民最起码的权力难道真的离我们这么远吗？

也许在政府工作的人员都应该是高学历的，政治过硬的，这样政府脸上也有光彩，这样才能更好的为大众服务，而事实真的如此么？我们的高考改革已经有了成功的先例，公务员招考也该考虑考虑’与时俱进’了。

改革是漫长的，吃饭是关键的，饿了，走了。

今天部门的一个同事很痛苦的向我求助。问题是关于一个新功能的测试，如果是一般的功能也就罢了，关键是这个功能是基于我曾做过的一个框架的，而这位同事由于是临时被指派的工作，对我的那个东西完全不熟悉。

问题就在这，当时写那个框架的时候目标就是为了部门内部其他项目的高度复用，也就是说其他项目如果有类似需求，使用我们的框架经过一系列配置就可以满足需求，至多需要一个简单的二次开发过程，可能需要提供若干业务相关的接口实现，编译到动态共享库中，把该库的名字和位置写到配置中即可。

这个框架的确消除了很多复杂的且易在各个项目中重复分布的功能，在部门的几个项目中都有使用；而且当初为了使框架更加通用，更加利于二次开发，我们采用了很多外部配置的方式，并且首次在C组采用xml的配置文件，毕竟xml的表达能力要比单纯的key = value型配置文件强大许多，可读性也更好，当初的目标毕竟是理想的。

实际的情况是，这些为了通用型留出的配置接口在实践中用的很少，但是其他第一次接触该框架的维护人员在了解它的时候又恰恰被过多的配置弄得晕头转向，无奈之下就来问我。复杂性由如何开发这些功能，到如何使用理解我的框架了。复杂性转移了。这也让我想起了最近看的关于J2EE中关于EJB的一些言论了。当初Sun在提出J2EE规范的时候更多的是考虑如何屏蔽掉分布式应用的复杂性，让开发人员不用关心分布式技术难点，结果导致最初的EJB只有Remote接口；而在实际应用中大部分Web应用都是部署在Single Machine Sing JVM上的，而Remote接口反倒降低了J2EE服务器的性能，这也许和复杂性关系还不是很大。继续说EJB，到后来开发人员发现要想开发出好的符合J2EE精神的应用，还是要去了解分布式协议的，这就大大提高了EJB的使用门槛，使大部门人望而却步。其实到后来的框架时代我觉得也是一样，框架的出现，一来可以让大家避免使用EJB的痛苦，开发出without EJB的应用，但是同时大家却都忘记了框架本身的复杂性了。试想要开发出好的Web应用，如果不对框架本身有所了解可能吗？特别是框架本身蕴含的各种设计思想，这也充分证明了复杂性的’此起彼伏’的特点。

下面的问题就是：复杂性没有消失，为什么大家还在用呢？目前软件业都在努力作着这些事情，即尽量让开发人员只关心问题域，业务域。无论是EJB还是各种轻量级容器框架的出现都是在努力向着这个方向前进，毕竟你在走向成功的道路上无需再reinvent the wheel了，虽然了解wheel的过程仍然复杂，仍然坎坷，但是照比以前也要好上很多了。

想到哪，说到哪，有些’语无伦次’，不知道大家能不能理解其中的意思。:)