最近個人的開源專案retrofit-spring-boot-starter突破一百star了，我非常地開心。也許對於各位技術大佬來說，一百star完全微不足道，但對於還是“鐵憨憨”的我來說，真的很不容易。乘著現在印象比較深刻，詳細總結一下整個過程。

我有程式碼強迫症

相信很多小夥伴跟我一樣，對程式碼都有一定的“強迫症”。碰到實現上不夠好或者使用上不夠方便的程式碼，總想好好封裝一下。這樣不僅能鍛鍊自己的抽象設計能力，更能顯著地提升研發效率，一舉兩得。時間回到2019年4月份，當時我們系統是一個spring-boot框架專案，專案中存在大量的http介面呼叫，但是呼叫的方式都是直接在業務方法裡面使用類似HttpUtil

當然，光有想法是不夠的，更重要的是如何實踐。我當時做的第一件事情就是想清楚自己最終想達成的目標，正所謂“以終為始”，先想清楚目標，再去努力實現。這裡，我聯想到了mybatis框架可以直接通過介面執行sql。實際上，不管是執行sql還是發起http請求，本質上都是一種資料互動形式，因此我最終定的目標就是支援spring-boot專案通過介面發起http請求。接下來第二件事就是程式碼實現了，我沒有上來直接擼程式碼，而是先去調研了一下相關的開源實現，畢竟站在巨人的肩膀上才能看得更遠。經過一番調研之後，最終有2個專案在我的考慮範圍之內，第一個是Feign

理想很豐滿，現實很骨感。retrofit官方並沒有提供與spring-boot專案快速整合的starter，這使得我不得不自己將其與spring-boot專案進行整合。實際上，我做的最初版就是做了一個整合，並且也達到過基本可用的狀態。如果故事止步於此，這件事我也就做到了勉強60分甚至是不及格的水準

開源專案是一件很酷的事

在每一個程式猿心中，擁有一個開源專案是一件很酷的事，我當時想的就是把這件事做成。但是真正要動手去做的時候才發現，事情比想象中要複雜的多。因為開源專案最終是要給其他人用的，所以我對自己的程式碼設計和質量都有更加嚴格的要求。而當時不得不承認的一個事實是，我對相關框架原始碼的理解遠遠不夠，換句話說就是我還不具備寫一個開源專案的能力。這個時候，我要做的事情就是先死磕相關原始碼。經過3個多月的時間，我終於把retrofit、spring和mybatis框架的核心原始碼全部理解了一遍。看過原始碼的同學應該都知道，看原始碼的過程多少帶有一些“煎熬”，但是認真啃完之後收穫也會很大。

準備工作完成之後，就開始正式進入程式碼設計和實現了。此時，之前啃原始碼的效果就明顯體現出來了，我在寫程式碼的時候會自然而然地聯想到開源框架的優秀實現，然後借鑑過來。這是一種很抽象的感覺，相信啃過原始碼的同學都有所體會。就這樣，編碼大概又花了2個月的時間，整個過程我都處在一個很興奮的狀態，記得那會睡覺的時候都在想怎麼擼程式碼。由於這些工作都是業餘時間進行的，因此這大半年時間裡面，我的業餘生活明顯變得非常充實，現在回想起來，確實很累但很有收穫。在此期間，我剛好也在做cms元件化框架的設計和實現，此時對spring框架的深入理解給了我非常大的幫助。到目前為止，cms已經是交易助手最複雜的業務，複雜度比交易助手其它所有業務加起來還要高，而cms元件化框架完美支援了相關業務的高效產出！

當一切準備就緒，接下來就是接受實際考驗的時候了，我們當時替換了交易助手2個Java專案的http呼叫，並且通過自測就直接上線了，上線之後效果很好，沒有出現任何異常。後來正式申請專案開源，整個過程比較漫長，大概花了4個月的時間，終於在2020年4月份稽核通過。我記得當時剛好是清明節，我在github上正式釋出了自己首個開源專案。不知不覺完成了目標，甚是欣慰。

突破百星

在接下來的2個月裡面，我主要是做了一些功能上的迭代優化，github上的star數量依然少的可憐。在6月份的時候，我準備寫2.0版本了。之所以要這麼快寫2.0版本，不是因為我們1.0寫的有多爛，而是因為這段時間，我思想上出現了一些轉變。之前寫1.0的時候，我完全站在自己的視角去想專案應該支援哪些功能，相容哪些框架，這誠然是我應該考慮的問題，但是好像偏離了方向，偏離了實際。我把實現做的複雜，僅僅是為了支援可能並不存在的需求。因此，在2.0的設計上，我做了大量簡化，僅保留最重要最核心的功能，我覺得只有使用者一下就能看懂你的設計，他們才會更有興趣和更有安全感。最後，我還花了整整2天時間為2.0編寫文件，這簡直是一件不可思議的事情。

由於我這個時候已經開始寫技術文章了，因此就在掘金上發了一篇介紹開源專案使用的文章。為了吸引眼球，我還特意取了一個很唬人的標題《spring-boot專案下最優雅的http客戶端工具，用它就夠了！》。沒想到一下子就火了，馬上就上了當天的熱門推薦，還給我帶來了30多個star。這對於平時都是“小透明”的我來說，真的是出乎意料。本來以為這件事兩天就過去了，但是github上的star一直都在緩慢上漲，因此我特意使用搜索引擎查了一下，發現很多平臺都有轉載的文章出現，這一切也算合理了。直到8月11號，github上的star一早上就漲了11個，這對於我來說太反常了，後來才發現技術公眾號大V@程式設計師DD(永輝雲創架構師，《Spring Cloud微服務實戰》作者，SpringCloud中文社群創始人，Spring4All社群聯合發起人)和@Java知音轉載了文章。不少網友在評論裡面表示了支援和認可，當然也有一些質疑的聲音，這裡很感謝@程式設計師DD對我說的話，“沒有最好，只有最合適，用心了！”，這也堅定了我持續進行迭代優化的信心。三天之後，開源專案順利突破百星，為了慶祝，直屬leader培麻麻還請全組的研發吃了頓飯。

總結

我其實只是做了一件很小的事情，唯一的區別是追求極致地去做好這件事情。在整個過程中，很感謝培麻麻的支援與鼓勵，同時也為貝殼這種對技術包容和支援的技術氛圍點贊。有時候我會想，如果當時做到60分就停止了，也許我不需要付出這麼大的心力，但也不可能有這麼大的成長。如果我們做的每件事，都只追求60分就行，那麼即使做再多的事情，我們依然只有60分的水平。相反，如果我們做每件事的時候都追求做精做細，雖然會更累更難，但自身的能力也會得到錘鍊和快速提升。正如Stanley所言，堅持長期主義，做難而正確的事情，寫開源專案這件事，正是如此！