前言
很高興和大家見面！
上週五我在掘金髮表了 《真香警告：即使不用餓了麼訂餐，也請務必收藏好該庫！》，文中主角 Linkage-RecyclerView 原本只是爲 《RxJava魔法師》 這個項目的需求而存在的，沒想到在各路讀者的積極參與下，讓一個本來默默無聞的項目，在內容發佈的第三天，登陸 GitHub 今日趨勢 Java 專區榜單前三，並在 5 天內做到 GitHub star 從 0 飆至 666。（不要慌，項目鏈接文末已給出）
在此我首先特別感謝熱心讀者的見證和參與。掘金社區、WanAndroid 讀者對源碼的認真閱讀和交流，讓我備受感動。
開源這個項目的初衷
每個架構都有專屬的用武之地
開源這個項目的初衷有兩個，一個是方便讀者藉助該項目深入理解，當我們爲項目選擇架構時，選材的依據是什麼。
就我當前的認知來看，項目開發，無非就是顧及 “配置解耦” 和 “職責分離” 這兩件事。
對於通用必用的控件庫和組件庫，我們可以將其抽取成模塊，做成可供多個項目依賴的第三方庫。
第三方庫的目標是讓使用者無需瞭解內部邏輯、通過外部簡單的配置即可輕鬆上手，因而第三方庫適合使用 MVP 架構，來實現 “配置解耦”。
對於多人蔘與的主幹工程，我們需要確保 UI 和 業務之間可以分工給不同的人協作，這就要求架構必須具備 “關注點分離（SoC）” 或 “職責分離（SoD）” 的特性。
因而我們可以在主幹工程中採用目前主流的關注點分離架構 JetPack MVVM，或者由我自主設計並在公司項目重構中採用的職責分離的 VIABUS Architecture。
未雨綢繆方能在關鍵時刻拯救自己
開源這個項目的另一個緣由是：
有些事我都已忘記，
但我現在還記得，
在一個晚上，
同事阿左問我，今天怎麼不開心。我說在我的想象中，有一個開源庫，
與衆不同最時尚，接入肯定棒，
整個 GitHub 找遍所有的 Repo，都沒有。
他說將來會找到的，
時間，時間，會給我答案。。
哈哈，開玩笑的。緣於，公司某個項目中的另一個需求：爲多級聯動表單動態綁定數據。
用過 Spinner 的讀者都知道，原生的 Spinner 在 onSelectItem 回調中存在延遲的 bug，雖然延遲只有 100ms，但對於哼哧哼哧地裝載、綁定、協調錶單數據的多級聯動表單來說，實在是致命的錯誤。
因而在那天晚上加班改需求的時候，我非常盼望着找到一款當下就可以使用的 PopupWindow + RecyclerView 實現的第三方 Spinner 開源庫。
然而，現實卻和我開了個大玩笑，我尋遍了 GitHub 倉庫，嘗試了若干個項目，都是隨便糊弄兩下、高度耦合的個人練手項目，這對於急着改需求的我來說，無異於火上澆油。
由於情況緊急，我選擇求助於同在加班的阿左，沒想到，阿左居然在項目閒時自己封裝了一個 Spinner 庫。
雖然一眼望去，Adapter 三方邏輯的解耦程度還有待提高，但這個庫既然能獨立存在、通過幾行代碼即可調用，對於彼時的我來說，就已經是最豐盛、最美的食物。
於是我毫不猶豫地將該庫用在了項目上，在幾經嘗試後，表單初始化數據終於如願地正常加載。
如何在 5 天內使 GitHub star 從 0 飆到 666
最後總結一下大家都關心的，如何讓自己的作品能被更多地訪問、讓 GitHub Star 數一路爬升：
即使忘了其他方法，也請務必記得這個不是方法的方法：
———— 向用戶提供價值。
什麼是價值？人們對一件事物有需求，這件事因而有了價值。
人們有什麼需求？人們面臨着什麼困境？這是每個想要服務於大衆的人都要首先考慮明白的。
換言之，我們所做的每一件事，都務必精準地化解目標用戶的痛點，唯有如此，纔有機會在紛雜的信息中脫穎而出，讓作品受到用戶的青睞和珍視。
每個人服務的領域不同、目標用戶也不同，因而用戶痛點需要自己在日常生活中投入大量精力去思考和領悟，這也是爲什麼文章我一週最多隻更新一篇的原因。
再者，就算是製作一款簡單的作品，也請務必抱着一顆敬畏的心。
在 Linkage-RecyclerView 開源的短短几天裏，我累計提交了 49 次代碼、多達 9k 行的代碼變動。
用戶不是傻子，代碼是好是壞，一眼就能看出來。唯有一絲不苟地對待工程設計和編碼，纔有機會讓用戶感到確定和安心。
此外，酒香也怕巷子深。
想讓精心打磨的作品讓更多的用戶接觸到，就要勇於在社交場合展示自己的價值。產品最終都是服務於人，務必多與用戶溝通，讓產品和個人品牌往更好的方向發展。
當然，口說無憑，以下貼上 別處看不到的、且大家喜聞樂見的 羣聊學（chui）習（niu）交流截圖：
考慮到我在技術社區發文，應以技術分享和經驗交流爲主。想目睹羣聊現場的朋友，請移一步到我的同名公衆號閱讀原文~
GitHub 項目鏈接：https://github.com/KunMinX/Linkage-RecyclerView