說說入職兩日的感受
伙計們，做好准備吧，南塵最近一定不可能日更的，不過不保證后面還會像現在這樣熟悉架構熟悉代碼到極度困，然后就想到我親愛的朋友們，然后再和你們吹會兒逼。
前面給大家講過，選擇了待遇相對偏低的咕咚，主要是因為一面的面試官，給了我很強的震撼力，讓我如同找到了同路人：同樣在為代碼質量而瘋狂努力。
今天，在他的指引下，總算對咕咚的架構有了較為深刻的理解。
果然，大一點的項目，總需要一個靠譜的架構，不然一定會面臨各種各樣的問題。
確實很刺激，這會兒公司還有一半多的員工在瘋狂干着自己喜歡的事。但絲毫不會影響，南塵會是那個每天來的最早的人~
今天看到致學發的關於我離職的文章，確實挺心酸的，不過好聚好散，還好我選擇了咕咚這樣一家還算注重技術的公司，我相信每一個致學人，也會飽含祝福。
對我來說，公司不在乎體量，我最在乎的還是團隊對技術的飢渴，很幸運在這一點，咕咚讓我足夠滿意！
咕咚強制采用 DataBinding && MVVM && ConstraintLayout 進行編寫代碼，之前也是一直沒有去學習了解 ConstraintLayout 這個神奇的布局，今天一看，真心超贊，但使用文章我就不寫了，鴻洋和郭霖已經把拖拽和直接手寫代碼的方式都講的很清楚了，感興趣的到他們的 CSDN 博客去仔細觀摩觀摩吧~
鴻洋的 ConstraintLayout 文章地址：https://blog.csdn.net/lmj623565791/article/details/78011599
郭霖的 ConstraintLayout 文章地址：https://blog.csdn.net/guolin_blog/article/details/53122387
對於 DataBinding && MVVM，可能小項目感覺不是很明顯，但相對體量大一點的項目就真的太有價值了解學習了。這也難怪，咕咚和美團都在面試的時候問了我 MVVM。
然后，KotLin 的話，看了咕咚的代碼，大概目前覆蓋比例 15%，最近本寶寶也是好好學習了一波 Kotlin，只能說，自從 Google 開始推薦 Kotlin 后，我們就不得不學習了。
Kotlin 中文教程網站：https://www.kotlincn.net/docs/reference/
強烈推薦書籍 《Kotlin for Android Developers》，目前中文版的 PDF 可在公眾號后台回復 "kotlin" 獲取，但更強烈推薦直接查看原作書籍！！！
大概也沒啥好說的，和我親愛的朋友們交流了一下，感覺狀態好了很多，我還是去默默做加班 dog 吧~
額，好像忘了一件事，之前在文章 說說過去一周的面試和想法（附美團咕咚面試題）中，有不少小伙伴留言問我面試答案。
在這里再說一下，面試這個東西，真的沒有標准答案，不過我可以給大家簡單講一下思路，要是以后有了時間，再詳細講吧。
RecyclerView 到底如何適配多種布局？
我看到問的最多的一個問題是，「RecyclerView 一個適配器如何適配多種布局」。
老實說，這個問題，我第一反應就是網上被人都寫爛了的萬能適配器，所以回答的就是根據不同的 Type 去設置 ViewHolder，畢竟我們通常設置 RecyclerView 的 Header 和 Footer 就是通過這樣的方式來實現的。但這樣的方式有一個非常嚴重的問題，就是其實根本就不萬能，當我們遇到各種 Item 布局的時候，我們又得重新維護 ViewHolder，一旦這個布局方式多了起來，就會存在嚴重的維護問題。
那我們還能有怎樣的思路來處理呢？
實際上，我們大多數，甚至是所有頁面都可以用 RecyclerView 來實現，只是每一項的 Item 顯示方式不一樣而已。為了減少維護成本，我們顯然不應該把判斷是哪種 Type 的代碼放在 RecyclerView 的「萬能」適配器中。而應該把這個邏輯抽象成一個接口，然后讓子類去自由發揮。然后在外面調用的時候，我們就只需要根據 model 的數據進行不一樣的布局填充就可以了。
你可能會有點暈，其實我自己也一樣，原諒我現在是從早上 7 點半一直干到現在的人，但我還是希望你能多看幾遍。
好吧，看了好幾遍了，還是一臉懵逼，姑且點到為止吧，時間關系，后面再做詳細闡述。
上千個 Shape 文件如何維護的問題。
這是另外一個大家很關注的問題，在咕咚的面試中，提到了 CardView 不利好的一面，並闡述了自己面臨成千上萬個 Shape 文件無法統一維護管理的僵局。
這個題，其實我認為可能沒有標准答案，只是面試官希望看你是否是一個喜歡並且善於思考的人吧。
一個開發人員稍微多一點的項目一定會遇到這樣的難題，我們很難統籌所有經手這個項目的小伙伴都能認真先去看一遍別人 Shape 里面的實現，更多的時候會采用 CardView 或者自己新寫一個 Shape 文件的方式。
CardView 可能功能沒有那么全面，而 Shape 可能面臨維護難題。
這是很現實的問題，那到底怎么解決這個尷尬的窘境呢？
經過思考，我們似乎可以通過自定義一個 View，支持各種圓角和其他的 Shape 或者 CardView 具備的功能就好啦~
可能有點投機取巧，不過至少說明我們很愛思考，哈哈。
寫在最后
還有不少人問我 API 選擇短連接而不是長連接的問題，我覺得這個問題，應該可以 Google 到吧，我就不想多提了。你可以思考一下，且不考慮客戶端的性能問題，服務器接受 N 個來自客戶端的長連接會怎樣巴拉巴拉
差不多了，這下要真的去加班 dog 了，要是大佬們看到錯別字，還請見諒，直接指出。我已經檢查了 3 遍了，但我這個狀態，恐怕難以處理~