說說入職兩日的感覺

說說入職兩日的感覺

夥計們，作好準備吧，南塵最近必定不可能日更的，不過不保證後面還會像如今這樣熟悉架構熟悉代碼到極度困，而後就想到我親愛的朋友們，而後再和大家吹會兒逼。

前面給你們講過，選擇了待遇相對偏低的咕咚，主要是由於一面的面試官，給了我很強的震撼力，讓我如同找到了同路人：一樣在爲代碼質量而瘋狂努力。

今天，在他的指引下，總算對咕咚的架構有了較爲深入的理解。

果真，大一點的項目，總須要一個靠譜的架構，否則必定會面臨各類各樣的問題。

確實很刺激，這會兒公司還有一半多的員工在瘋狂幹着本身喜歡的事。但絲絕不會影響，南塵會是那個天天來的最先的人~

今天看到致學發的關於我離職的文章，確實挺心酸的，不過好聚好散，還好我選擇了咕咚這樣一家還算注重技術的公司，我相信每個致學人，也會飽含祝福。

對我來講，公司不在意體量，我最在意的仍是團隊對技術的飢渴，很幸運在這一點，咕咚讓我足夠滿意！

咕咚強制採用 DataBinding && MVVM && ConstraintLayout 進行編寫代碼，以前也是一直沒有去學習瞭解 ConstraintLayout 這個神奇的佈局，今天一看，真心超讚，但使用文章我就不寫了，鴻洋和郭霖已經把拖拽和直接手寫代碼的方式都講的很清楚了，感興趣的到他們的 CSDN 博客去仔細觀摩觀摩吧~

鴻洋的 ConstraintLayout 文章地址：http://www.javashuo.com/article/p-vvqpebme-bt.html

郭霖的 ConstraintLayout 文章地址：http://www.javashuo.com/article/p-euyilgtm-ck.html

對於 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 遍了，但我這個狀態，恐怕難以處理~