大物始於小:我是如何做到 GitHub star 在 5 天內從 0 飆至 666 的

KunMinX發表於2019-05-17

本文由作者 KunMinX 原創,與 7 萬進階讀者共同向上生長 ?

前言

很高興和大家見面!

上週五我在掘金發表了 《真香警告:即使不用餓了麼訂餐,也請務必收藏好該庫!》,文中主角 Linkage-RecyclerView 原本只是為 《RxJava魔法師》 這個專案的需求而存在的,沒想到在各路讀者的積極參與下,讓一個本來默默無聞的專案,在內容釋出的第三天,登陸 GitHub 今日趨勢 Java 專區榜單前三,並在 5 天內做到 GitHub star 從 0 飆至 666。(不要慌,專案連結文末已給出)

大物始於小:我是如何做到 GitHub star 在 5 天內從 0 飆至 666 的

在此我首先特別感謝熱心讀者的見證和參與。掘金社群、WanAndroid 讀者對原始碼的認真閱讀和交流,讓我備受感動。

開源這個專案的初衷

每個架構都有專屬的用武之地

開源這個專案的初衷有兩個,一個是方便讀者藉助該專案深入理解,當我們為專案選擇架構時,選材的依據是什麼。

就我當前的認知來看,專案開發,無非就是顧及 “配置解耦”“職責分離” 這兩件事。

對於通用必用的控制元件庫和元件庫,我們可以將其抽取成模組,做成可供多個專案依賴的第三方庫。

第三方庫的目標是讓使用者無需瞭解內部邏輯、通過外部簡單的配置即可輕鬆上手,因而第三方庫適合使用 MVP 架構,來實現 “配置解耦”。

viabus_flow_cn.png

對於多人蔘與的主幹工程,我們需要確保 UI 和 業務之間可以分工給不同的人協作,這就要求架構必須具備 “關注點分離(SoC)” 或 “職責分離(SoD)” 的特性。

因而我們可以在主幹工程中採用目前主流的關注點分離架構 JetPack MVVM,或者由我自主設計並在公司專案重構中採用的職責分離的 VIABUS Architecture

未雨綢繆方能在關鍵時刻拯救自己

開源這個專案的另一個緣由是:

有些事我都已忘記,

但我現在還記得,

在一個晚上,

同事阿左問我,今天怎麼不開心。

...

我說在我的想象中,有一個開源庫,

與眾不同最時尚,接入肯定棒,

整個 GitHub 找遍所有的 Repo,都沒有。

他說將來會找到的,

時間,時間,會給我答案。。

哈哈,開玩笑的。緣於,公司某個專案中的另一個需求:為多級聯動表單動態繫結資料。

用過 Spinner 的讀者都知道,原生的 Spinner 在 onSelectItem 回撥中存在延遲的 bug,雖然延遲只有 100ms,但對於哼哧哼哧地裝載、繫結、協調錶單資料的多級聯動表單來說,實在是致命的錯誤。

因而在那天晚上加班改需求的時候,我非常盼望著找到一款當下就可以使用的 PopupWindow + RecyclerView 實現的第三方 Spinner 開源庫。

大物始於小:我是如何做到 GitHub star 在 5 天內從 0 飆至 666 的

然而,現實卻和我開了個大玩笑,我尋遍了 GitHub 倉庫,嘗試了若干個專案,都是隨便糊弄兩下、高度耦合的個人練手專案,這對於急著改需求的我來說,無異於火上澆油。

由於情況緊急,我選擇求助於同在加班的阿左,沒想到,阿左居然在專案閒時自己封裝了一個 Spinner 庫。

大物始於小:我是如何做到 GitHub star 在 5 天內從 0 飆至 666 的

雖然一眼望去,Adapter 三方邏輯的解耦程度還有待提高,但這個庫既然能獨立存在、通過幾行程式碼即可呼叫,對於彼時的我來說,就已經是最豐盛、最美的食物。

於是我毫不猶豫地將該庫用在了專案上,在幾經嘗試後,表單初始化資料終於如願地正常載入。

如何在 5 天內使 GitHub star 從 0 飆到 666

最後總結一下大家都關心的,如何讓自己的作品能被更多地訪問、讓 GitHub Star 數一路爬升:

即使忘了其他方法,也請務必記得這個不是方法的方法:

———— 向使用者提供價值

什麼是價值?人們對一件事物有需求,這件事因而有了價值。

人們有什麼需求?人們面臨著什麼困境?這是每個想要服務於大眾的人都要首先考慮明白的。

換言之,我們所做的每一件事,都務必精準地化解目標使用者的痛點,唯有如此,才有機會在紛雜的資訊中脫穎而出,讓作品受到使用者的青睞和珍視。

每個人服務的領域不同、目標使用者也不同,因而使用者痛點需要自己在日常生活中投入大量精力去思考和領悟,這也是為什麼文章我一週最多隻更新一篇的原因。

再者,就算是製作一款簡單的作品,也請務必抱著一顆敬畏的心。

在 Linkage-RecyclerView 開源的短短几天裡,我累計提交了 49 次程式碼、多達 9k 行的程式碼變動。

大物始於小:我是如何做到 GitHub star 在 5 天內從 0 飆至 666 的

使用者不是傻子,程式碼是好是壞,一眼就能看出來。唯有一絲不苟地對待工程設計和編碼,才有機會讓使用者感到確定和安心。

此外,酒香也怕巷子深。

想讓精心打磨的作品讓更多的使用者接觸到,就要勇於在社交場合展示自己的價值。產品最終都是服務於人,務必多與使用者溝通,讓產品和個人品牌往更好的方向發展。

當然,口說無憑,以下貼上 別處看不到的、且大家喜聞樂見的 群聊學(chui)習(shui)交流截圖:

大物始於小:我是如何做到 GitHub star 在 5 天內從 0 飆至 666 的

考慮到我在技術社群發文,應以技術分享和經驗交流為主。想一睹群聊現場的朋友,請移一步到我的同名公眾號原文閱讀。

GitHub 專案連結:github.com/KunMinX/Lin…

xzl短

看不過癮?這裡只為你 而準備了一份 簡潔有力的 《重學安卓》認知地圖 ?

相關文章