关于Java面试的想法与一次面试的吐槽
关于Java面试的想法与一次面试的吐槽
今天这个事，我其实很不爽，这让我感觉很多人缺乏面试的能力。缺少面试思考。所以我先写一下我对面试的一些看法，后面会放上我最近一次面试的一些想法。
工程能力与基础
从今年年初开始，我已经面试8场了。只有一个公司面试了算法（实际手写）。Java这边对编程的基础的考察还是太少了。（这里的基础指的是数据结构，等等）
另一方面，国内Java工程师面试，缺少的实际的工程能力的考察。
国内很多人吵吵程序员干到三十多岁不行了怎么怎么地，java程序员本身就是偏向于工程的，这些干不下去的人缺少工程的意识，写代码的时候一腔热血，上来直接干，啥辅助设计都没有，最后结果就是越改越烂，如此反复，心力憔悴。他们在这样循环中，仍然不能找到真正的问题所在，缺乏找到正确问题的能力，这是很悲哀的。
实际的工程能力，与常见的面试问题截然不同。
实际工程能力合理的考察方式就是写代码，给一天或半天时间写代码，有没有其他方式我也不知道。就我目前的理解来看，可以参考一些国外做软件工程的公司面试办法。这是一个捷径。
程序员的核心能力
我认为程序员最核心的是“模型的理解能力”。很多人会回答核心能力是解决问题，我理解解决问题只是其中很小的一部分，远没有达到核心的水平。
我这里举个例子，我要实现一个单例，abcd四种方式都可以，每种方式都能解决“单例”这个问题。在这种情况下选一个最恰当的才是程序员应该做的事情。怎么才能选择一个恰当的？只有理解不同的组织设计方式，才能够有效的解决问题。
解决问题的方式方法是非常重要的，不管黑猫白猫，抓到耗子就是好猫，这句话本身就是错误的，有的猫为了抓到老鼠，打碎了所有家具，有的猫把老鼠逼出门在外面抓，虽然不管如何处理耗子都没了，但是影响截然不同。解决问题的方式也是一样，正确的解决思路需要做的就是理解现有问题的模型，设计目的等等，这样才能合理的解决问题。而不是解决小问题，引入大麻烦。这就回到我说的核心能力上了，模型的理解能力。
比方说反射的整体模型设计，我目前理解到的一点是这样的。普通的代码是针对业务进行抽象设计，而反射是针对整个java代码进行抽象设计。代码有什么结构，可以加什么东西，反射就可以拿到什么。实际上就是这么回事，并不难。
这个能力的面试方式，坦诚讲，我不知道。但是我们换个角度思考，面试官如果觉得解决问题能力是最重要的，他就会问，做过什么事情，解决了什么问题，等等。这真的能反映出程序员的解决问题能力么？也不见得吧。
用过
还有一部分人的考察，偏向于你是否真的用过，其实是可以理解的。他的目的只是来判断你是否真的用过。所以他才会问你用过xxx么，用过xxx么，xxx是干什么的，说一说 spring 的常用注解，bean几种配置方式，甚至让你说一些配置条目。
关于这部分的考察，我是可以理解的。不过有人公司的做法是很过分了。如果真的这么看重这种东西，reference比我更适合当程序员，它啥都有。
关于基础的误解
还有一点就是，很多国人程序员，误会了基础与构造Java的基础。这两个明显不是一件事情。
基础是最常用的东西，而构造Java的基础指的是用什么做出来Java。我这里举一个例子，构造人的基础是分子原子，而人生活的基础是技能啊，交流啊，这些东西。有些程序员就总把这些事情混为一谈。
《java核心卷ⅠⅡ》就在我头顶上摆着，我翻了一遍，也没看到上面说ClassLoader的内容。这类东西确实是构造Java语言的基础，但是离日常使用的基础来说，远着呢。
当然也不是说这些知识不重要，为了解决特定问题再去看就好了，又不是很难的东西。知道“有”这个东西才是重要的。这就是知道自己知道与不知道。
关于知识深度
再提一点 关于知识的深度方面。有一部分人提出的观点是这样的：先问一部分东西，试探一下面试者的水平，然后再挑一两个重点深入的问，如果对方一直能回答上来，那说明 接受面试的人深度是足够的。这个观点就目前看来是被绝大部分程序员接受的。
但是我一直对这个观点抱有疑问的，这种考查方式，考察的内容真的算是深度内容么？这种方式真能考察出来么？
不妨用因果来进行一下推断。
假设 一个程序员对知识深度掌握较好（这是因），那么结果是什么呢？结果之一是 深入了解的内容 可能和面试官问的问题一样，也可能不一样。如果面试者能回答上来面试官的提问，说明深度足够。如果回答不上来呢？这就说明面试者深度不够么？不一定吧。
单拿面试的那一两个小时，面试官问了问，面试者说不上来怎么回事。然后面试官就把这个面试者判定为 对知识深度掌握不好。
我这里举个例子。我前几天比较好奇，java如何获取泛型（参数化类型）的类型，找了一些实现，然后看了些相关的type类型继承关系、操作办法，看了Gson的typeToken设计，然后又看到Type和Class<?>的类型有关系。然后又联想到注解的整个设计体系，突然间理解了整个反射的设计思路。
面试的时候，从来没有人问过我这些东西，甚至连相关的一点点都关联不起来。但我并不认为深度不够。多亏我的内心还是足够强大的，能够想明白这些事情。可怜的是有些人真的就被打上深度不够的标签了。然后这些人就去准备JVM，准备多线程。打着面试造航母，入职拧螺丝的旗号去工作，实际行为是非常可怜的。
一次面试的吐槽
关于书的好坏
《Java并发编程实战》讲了并发组件的整体设计，使用场景。这也是我为什么说这本书好的原因。有了这本书明书，在Java并发领域，能让读者少一两年的无用功。这个效果是《Java并发编程的艺术》这本书永远达不到的。这是我的理解。
关于Srping MVC五大组件
五大组件 这个事情，本身是一种名。叫起来就像口号一样，
这个称呼只有csdn到处抄袭的时候才会说，Srping MVC本身就不是国人写的东西，较为准确的出处就是官方文档。所以我就试着换了关键词搜索相关的英文内容，搜不到。
换句话说，五大组件这个说法，可能就是某个国人率先提出来的一句口号，然后所有的博客跟着抄。
其实现在人需要的能力之一就是辨别真伪。你看的资料是否可信？是否都有依据，出处是否可信？是否是谣言在传来传去？
我这里举一个我发现的一个点作为例子。引一下我之前个人笔记
目前，网络上大部分的说法都有误差，而且误会很大，首先要区分一个概念，不要把swagger 和springfox 混为一谈
网上大部分人说的
springboot与swagger集成，说的都是 springfox 而非 swagger官方的东西。swagger官方的东西是与 JAX-RS继承配套使用的，与springboot 或者是 springmvc 配套使用的工具是没有的。
早期有个人做了个springmvc-swagger 后来有个德州佬觉得挺好的，就拿过来了，他按照自己的思路改了改，就做了一部分改进。
他的改进思路是：他觉得swagger-core侵入性太强了，注解太多不好处理，所以他的开发 逻辑是尽可能的少用这些注解来实现功能。虽然他也引用了swagger的注解包，但是很多功能都没有实现。很难受就是了。
这是我不愿意用的问题之一，
再一点，这个德州佬不爱写注释。烦死了。
如果想用swagger官方的东西，去core的仓库，里面的wiki写的很清楚，这个东西一般是与那种cxf序列化框架 集成的。而且文档很详细。
如果仍然想用springfox的东西，那就只能接受他的使用逻辑了。
关于设计模式
用设计模式，要解决什么问题。如果真的本着这个目的去用设计模式，是无法使用的。
为什么？设计模式，是一种总结出来的范式，它是一种类似于语言语法的东西。
母语是中文的中国人，不管说长句还是短句，简单或复杂句子的时候，极少使用语法规则去套用。
设计模式也是一样的，当你在做Java设计的时候，需要的不是用设计模式来套，而是把东西设计出来，自然而然的体现出设计模式。
要想做到自然的设计模式，首先就是不要为了设计而设计。
这里还是用装饰器来举例。io包，用装饰器来处理的根本原因就在于 stream流本身用一次就没了，复制很麻烦，处理成本太高了，通过装饰器这种方式，较为简单的增加新功能。
所以从以上实际用法，总结出来的装饰器的使用前提是
- 实际对象处理成本比较高
- 不管如何装饰，对象本身是一个东西。
实际的使用场景多少会有些变化，目前我印象中的，使用装饰器的东西，好像还有图形界面的相关对象。因为前提很像。
我这里还在runoob上 查了一下装饰器 主要解决的问题。上面是这么说的：
主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。
这不是废话么，所有的设计模式和各类书上讲的都是这个事情，让东西更少一点，重复代码少一点。
关于G1
关于G1是不是 JDK 8 的default gc 不是很重要，谁能不犯错呢。
我这里不爽的是，大家都是一线干活的，面试与被面试地位的不平等是让我很不爽的。在面试的场景下，大部分面试者会认为自己是错的，面试官会认为自己的是对的。