做java的这段日子，逐渐明白了一点，公司基本上都是按经验取人的。经验这个东西在java的世界里，一点都不抽象，就是很具体的单位——年。
虽然面试现在所在的单位时，信誓旦旦的对我说是给我争取了与能力相符的待遇，但是在我研究后发现，还是跟年挂钩的。我还是没有跳出工作年份的梯队。公司还是按照市场的普遍价格算的。其实一个技术人员的实力，单从面试又如何得知。面试官能考察的，只是面试官能力范围内的，所谓以己之长比人之短。在面试官的能力范围内，你的某方面能力达到了，就能认可你，其他方面再好，他不懂，也没有那个自信去支持你。所以这个通用的以年为单位的评估方式，简单而直接，被广泛使用。
那么以工作时间来判断能力，有多少可信性呢？其实在某些方面还是比较有依据的。
最近接收了一个二手项目，比较头疼，但是又让我欲罢不能。我并不认可这个项目的设计，但是具体在什么地方，又很难说的完整。
比起另一个，这个系统似乎还没有被玩坏，还能看清楚本来面目，原有的封装和调用基本上都在正常运转，改起来应该能舒服一点。从修改的过程中，我似乎能感觉到，这个系统的原作者应该是个更有经验的家伙，很多调用的api都是我不曾使用的，但是运用的却又比较恰当，就如同同样用英文表达一个意思，用简单的词汇生硬的表达，跟有合适的复合语法加上多种恰当的词组俚语修饰，所表达的效果是完全不同的，在这个方面很值得我借鉴。比方说，我认为自己使用映射的知识已经足以应对所有的情况，但是我事实上只知道怎么样可以获取一个类的class对象，遍历方法和字段，然后invoke。但事实上，关于映射有非常丰富的api可以使用，虽然在java文档中都可以查到，可是在需要使用的时候，我可能无法想到他们，更别提用他们来支撑我的设计了。这些东西确实是需要积累得到的。
但是这种积累并不意味着一切。因为这并不意味着他能做出比我的更好用的系统。在思维层面，这个老鸟比我差多了，毫不客气的说。他的封装做的相当失败。例如，一个用来导出excel文件的插件类，居然需要request对象作为参数。。。很难想想我是否也会做这么差劲的封装。不仅如此，更多的更普遍的问题是，他是为了封装而封装，在检查算法的时候，我看到，在一个很长的方法中，会有某个调用，在这个调用中，其实只有一行代码（我知道在某些情况下这是有意义的），似乎他只是为了让别人看不懂而做的封装，可读性很差。更合理的应该是，封装是对所要处理的问题的合理化拆分，每个模块都有其明确的意义。他给我一种感觉，他本来不会封装，然后刚刚学会了封装，就故意找了一个很容易找到的地方，做了一个小练习，这完全颠覆了原先的老鸟形象，所以我说，他就是不想让我看懂他写的东西。可能他更需要的是代码混淆技术。
我认为，真正让我们做出一个好的设计的，并不是经验，而是数学模型。理论上我们可以对所有的软件系统做数学建模，可能这个过程往往都是隐式进行的。数学模型决定了我们如何从程序的角度看待一个需求。经验或许能对建模能力产生一些影响，但是单纯的经验积累并不足以取代数学思维的作用。或者我们应该试着做一些专门的练习，但是一个庞大系统的建模，对记忆力也是个不小的挑战，如果记忆力不够，很难有足够的空间进行庞大的构思。嗯，这也解释了年龄对程序员的作用，似乎我也应该考虑怎么可以维持记忆力不会衰退，听说玩拼图是个不错的办法。数学建模的选修课曾经我真的很认真的学习过，但是大部分都还给老师了，好可惜，不过还是能记得一些，记得有个问题是说，板凳四个腿，怎么在地面上放平的问题，就是说我们生活中日常的这些问题，其实都是可以对其进行数学建模的，然后就可以转化为数学问题，这样问题就可以通过数学技术来解决。所谓软件工程这个课题，其实也是一种数学建模问题，只不过更加具体化了。如果从通俗一点的问题的建模上开始考虑，那么软件工程的出现也就不再那么突兀了，数据流图，e-r图其实也是一种匹配性的模型。为什么有些系统维护起来那么困难，系统的实现本身就是某种固化的数学模型，就如同一个数学题，解法有很多种，但是难度是各不相同的，而有一些解法似乎还更容易出现计算错误，另一些或者还会引出一些世界未解之谜，我们不是数学家，搞理论研究是数学家的事，咱们技术人员当然还是要用更容易的办法做。所以才需要更加优化的数学模型，嗯，这个优化的过程或者在码字之前就该进行了。也许只是在头脑中的一种构思，但是现实是，许多人甚至连构思都没有。
现在，我已经离showmethecode模式渐行渐远了。继续敲代码能带来的提升，如果只是像现在这样，我觉得，玄！如果有这样子敲了5年的家伙？我想知道是怎么做到的。在经验饱和之后，巩固基础才是首要的，就目前接触的这些技术而言，嗯，手上这个项目大概还够我再看一阵子吧。