面試常問的話題，你看原始碼學到了什麼？
前言
在看了肥朝之前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一樣,也是從後續 可能拓展性 的這個角度來做分層
寫在最後
當然不少同學遇到面試 造出了火箭 ,順利入職後卻發現做的是擰螺絲的活!此時手中的大刀摁都摁不住!
但是其實技術是要服務於業務開發的,在業務開發中,需求頻繁改動是家常便飯.除了向肥朝借讀以下書籍之外
我們也可以把業務程式碼,按照我們從原始碼中學來的方式進行編碼,這樣才是真正碼出高效,每天早點下班,不至於出現公司沒給夠你泡妞的錢,還剝奪你泡妞的時間,最後搞壞了你泡妞的身體!
