面试常问的话题，你看源码学到了什么？

前言

在看了肥朝之前Dubbo源码解析系列的粉丝.出去面试一般都是上来一波操作猛如虎的源码分析, 技惊四座 !当然也有一些喜欢 打我脸 的粉丝做了如下反馈:

言归正传,在面试"造火箭"的过程中,最常问的又最有区分度的一些问题

• 你对XXX源码这么熟悉,那有没有遇到过什么坑?参考[ 面试官问我，使用Dubbo有没有遇到一些坑？我笑了。 ]

• 你看了这么多源码,那请问学到了什么?

坦白说,在面试官稍微一深入原理就喊疼,只能被迫换个姿势继续深入其他话题的情况下,一般是不太可能遇到这两个问题的.但是如果你认真看过之前的源码解析和 真实 场景源码实战系列,被问到这个两个问题时又如何做到和肥朝一样 坐怀不乱 ?

本文并非要做出所谓的标准答案,毕竟每个人看问题角度不同,学到的自然不懂,本文主要希望通过抛砖引玉的方式,让你在看源码时经过 深度思考 ,而不是只是为了面试装装逼.如果只是为了装装逼,那和 每天喊着减肥,却只是为了吓一吓身上的肉 一样,毫无意义!

源码中的分层结构

SpringMVC

我们先来看一下SpringMVC中 HttpMessageConverter 的分层结构设计,规范的命名让我们很容易从单词中就很容易猜出,这个类的作用是,将数据做相应转化并响应回去.大白话就是,把你controller的实体类,转换成相应的数据给前端.那我们来看一下,这个类,SpringMVC是怎么对这个需求进行代码分层结构设计的

仔细分析我们不难发现,最外层的是 响应格式

MappingJackson2HttpMessageConverter  (json)
MappingJackson2XmlHttpMessageConverter  (xml)

再往里,就是 序列化 工具 选择

AbstractJackson2HttpMessageConverter   (jackson)
ResourceRegionHttpMessageConverter
GsonHttpMessageConverter    (gson)

再接着,就是公共的抽象类.

那么关键问题来了,它为什么这么设计,以及这么设计,会有什么好处?

那我问你,假如你需要增加一种序列化方式,比如fastjson,你会怎么做?

很明显,照葫芦画瓢,你参考 jackson 和 gson 的做法都知道,是需要继承 AbstractGenericHttpMessageConverter ,然后新建一个 FastJsonHttpMessageConverter 的类做额外的特殊处理啦.这就是大佬们常说的 好的代码会说话 .

另外他这么分层,还有一个好处.你想一下,像这种把实体类转换成相应数据的功能,如果要拓展,我们会拓展哪几个方面?肥朝认为,无非是两个方面,一个是 响应的格式 ,比如 JSON 、 XML 、 String .另一个是, 序列化的工具 ,比如 fastjson 、 jackson 、 gson .你再看一下这个分层,无论是改 响应的格式 和 序列化工具 都很轻松,维护性好很多.并且拓展后,单元测试也能细粒度测试拓展的功能,不至于出现代码深不可 "测"

可见,在代码分层时,我们其实是可以从后续 可能拓展性 的这个角度来做分层

Dubbo

肥朝公众号的粉丝大部分是看过Dubbo源码解析系列的,因此我们有必要来看看Dubbo里面又是怎么做的呢?

内容太多,我们可以拿 Remoting(远程通讯)模块 来看看.他主要分 Exchange(信息交换层) 、 Transport(网络传输层) 、 Serialize(数据序列化层) 这么几层.

Exchange(信息交换层): 封装请求响应模式.

Transport(网络传输层): 网络传输方式的统一接口

Serialize(数据序列化层): 数据的序列化

从刚才的源码经验来看,我们想想,对于 远程通讯(Remoting) ,他为什么要这么分层?

对于远程通讯这个需求,我们可能会有哪几个方面的拓展需求?

• 请求响应模式(同步、异步)

• 比如网络框架的选择(Netty,Mina,JDK API)

• 比如序列化方式(Kryo,JSON,JDK序列化等)

可见,Dubbo在做代码分层时,和SpringMVC一样,也是从后续 可能拓展性 的这个角度来做分层

写在最后

当然不少同学遇到面试 造出了火箭 ,顺利入职后却发现做的是拧螺丝的活!此时手中的大刀摁都摁不住!

但是其实技术是要服务于业务开发的,在业务开发中,需求频繁改动是家常便饭.除了向肥朝借读以下书籍之外

我们也可以把业务代码,按照我们从源码中学来的方式进行编码,这样才是真正码出高效,每天早点下班,不至于出现公司没给够你泡妞的钱,还剥夺你泡妞的时间,最后搞坏了你泡妞的身体!