我是如何把github開源項目作到5300+ star的

前言

我開發的開源文檔工具在github上上升到了5300+的star ，受到了部分開發者的歡迎。因而便想寫文章與你們分享一下我在整個創做過程當中所用到的技術以及相關技能。

任務管理

不管是作本身規劃的產品功能，仍是作用戶反饋過來的bug，最終都須要把這些點細化成一個個單獨的小任務，串聯執行（畢竟本身是單我的力）。在這點上，我主要是利用團隊看板來實現個人任務管理。團隊看板工具備好多，搜索一下就好，我我的目前在用tower.im

看板上我新建五個清單，分別是「在作」、「要作-高優先級」、「要作-低優先級」、「待定」、「遺留問題」，我這樣分類是有技巧的。首先，它有優先級劃分，保證先作重要的事。其次，它有狀態管理，方便我隨時中斷某個任務，過一段時間再回來繼續任務。同時，它也能應對新任務——好比說新需求進來，我先放在「待定」，等有空了再分配到其餘清單去。最後，它還有「遺留問題」清單，可讓我不在某個「疑難雜症」上卡住太多時間，快速推動下一個任務。

本地開發

用Linux或者MAC會很是方便開發、搭建測試環境等，對開發者的方即是毋庸置疑的。可是電腦有時候須要玩遊戲，須要裝一些專業大型軟件。從兼容性和普遍性的角度來考慮，我我的仍是使用windows系統。在win上，我使用的是Vagrant + virtualbox這個組合。Vagrant是一套工具，幫助你快速在win系統上，利用virtualbox搭建起虛擬機，從而方便使用linux或者MAC(好比上架蘋果app的時候我須要MAC虛擬機)。關於這點，能夠參考我幾年前寫的一篇教程：blog.star7th.com/2015/06/1538.html

代碼管理

我用git做爲代碼版本管理工具，同時使用tortoisegit進行可視化操做。
說一下我是怎麼維護官網在線版showdoc和開源版showdoc的。我在本身的服務器安裝一個私有版的gogs做爲私有git管理平臺。功能開發好了，我再推送到github上去。官網版和開源版一開始是同一個倉庫裏的不一樣分支。後面它們的差別（尤爲是後端代碼的差別）愈來愈大，因此我乾脆把它們分紅兩個不一樣的倉庫了。作開發的時候，我通常是如今官網版上作開發以及測試驗證，而後再用tortoisegit的代碼修改差別比較功能，把功能遷移到開源版去。

說一下分支管理策略。我至少創建兩個分支——主分支和開發分支。新功能會在開發分支作，驗證好了再合併到主分支來。用開發分支的時候也有技巧。好比說，一個大的功能能夠基於開發分支再新開一個分支去作。例如我今天想作A功能，那就在A分支上操做。可是A功能遇到瓶頸了，這會兒我暫時沒精力去找bug，因此此時我能夠再基於開發分支開啓B分支，繼續作B功能。這很重要，由於在人力有限的狀況下，我作什麼事情都是串聯的，同一時刻只能作一件事。這樣的策略有利於保證本身隨時中斷、隨時上手任務，靈活地安排不一樣的時間去處理容易的或者棘手的問題。這個過程也須要配合上面說到的團隊看板使用。中斷前要記錄好進度，方便本身隨時恢復工做。

shell自動化腳本

我爲showdo寫了三個shell自動化腳本。其做用分別是自動化部署showdoc，自動生成api文檔到showdoc，自動生成數據字典到showdoc。之因此選擇shell而不是其餘腳本語言（如python），是由於shell基本能夠運行在絕大部分linux上，部分運行到win上（須要安裝工具），兼容性超好，依賴很是少。根據反饋，受到的好評比負面評論多得多。自動化腳本大大節省了使用者安裝環境的麻煩，下降了showdoc的使用門檻。showdoc大部分的用戶不是php開發者，要他們安裝php環境仍是挺折騰的。有了一鍵腳本，他們用得方便，我也省心，不須要在解決新手反饋上花太多功夫。這個方法是具備普適性的，而且語言無關（由於一鍵腳本使用docker跑服務）。是能夠大量應用到開源項目中，很是有利於開源項目的代碼分發。

順便強調一下，作web應用開發的人，尤爲須要克服一下對shell腳本的疏遠感。我之前以web開發爲主的時候就會潛意識地疏遠shell。在騰訊的時候向另外一個技術棧的同事請教了下，發現其實仍是蠻簡單的。只是由於本身過去心理上的疏遠感致使本身沒想過要去寫shell。跨過這個心理檻，就會擴展自身的能力邊界，寫起來跟其餘語言沒有太多區別，僅僅是須要多搜索查詢下語法而已。

後端開發

多是由於showdoc僅是一個小產品，涉及到的後臺邏輯並不複雜，因此我在開發後端花的時間很少，基本上都是CRUD，對數據庫進行增刪改查操做。須要多動點腦力的地方在於團隊管理功能，新建多幾張數據表聯合實現精細化權限控制。

showdoc後端主要採用的是國產框架thinkPHP。這個框架有好也有很差。很差的地方在於它的框架約定、生態共享比較通常，好的地方在於它能夠快速擼出一個東西來，並且兼容性還能夠。這是四年前我剛開發showdoc時的決定，後來也懶得換框架重寫了，因此沿用至今。技術是相對落後了一些，可是也勝在兼容性好，能夠兼容老的php環境和一些老的服務器。這個仍是挺重要的，由於showdoc是開發輔助性質的工具，協助寫文檔。兼容性越好就越容易被各類各樣的羣體接受。我的以爲這一點比用各類先進技術要更實用一些。固然了，若是是如今新開發其餘項目，我應該會使用laravel，或者NodeJS寫的eggjs。

前端開發和UI

我在前端開發上花費的時間比後端開發時間多不少。多是由於這是個體驗型產品，須要把前端體驗作好。起步一個產品的前端頁面時候，我建議必定要選好一個UI框架。好比我選擇的是ElementUI作showdoc，而runapi則使用museUI（runapi是輔助showdoc用的一個在線api測試工具）。

showdoc用的編輯器是editor.md，是幾年前的產品。雖說它代碼組織方式可能有點落後，且原做者彷佛有放棄維護的趨勢。但我以爲它功能強大且簡潔美觀，因此我花了時間將它封裝成了vue組件，而且修改其源碼增長了安全性。

項目拖拽和頁面排序我用的是vue組件vuedraggable，還蠻好用的。之後有拖拽的需求我估計仍是用它。

圖標設計方面，可使用UI框架內置的字體圖標，也能夠用阿里媽媽的矢量圖標庫。或者本身使用Iconion進行圖標設計。這裏我強調一下Iconion。這個工具能夠很是簡單快捷地使用一些預約的圖案和背景，組合成一個快速可用的產品圖標。showdc的產品圖標就是這樣製做的，快速省時地作到媲美專業的效果。若是之後把產品作大了，能夠考慮請設計師設計。但在項目前期，用Iconion就夠了。

在這裏要提一下前端技能的重要性。雖說UI框架以及相應的工具可以幫助你節省不少時間。但若是想作好一個產品的體驗，那麼其涉及到的UI和交互可能超出框架自帶的範圍。所以本身必須學會使用原生css，會js交互，會封裝組件。並且，前端技能跟下面要說的app多端開發也有幫助。

app多端開發

關於移動app產品原型設計，我很建議使用「墨刀」來作簡單的原型規劃。有了一個可視化的原型，真的能節省不少大腦時間，讓你在開發階段的時候能夠專一代碼，而不須要寫一下代碼，又回頭思考下一步作什麼功能，這樣的來回切換至關耽誤效率。

app開發我用的是uniapp，使用html5等前端技術把代碼封裝成手機本地app，包括安卓app、蘋果app，甚至小程序。這種技術幾年前就有了，可是性能一直不溫不火。2019年的時候我看到了這塊發展得仍是能夠的。因此就產生了作showdoc app端的想法。不過因爲showdoc重在pc web端，手機只是起到輔助做用，因此我沒有很精心去作。大概把web版簡化一下，複用一些組件，重寫下前端，而後就上線了。順便說一下，我作得比較精細化的app是時光樹洞（blog.star7th.com/2019/09/2380.html) ，這款app的UI就花了點心思。

若是要讓我評價這種混合型app和原生app，我會說，確定原生app最好。只是出於成本和人力的考慮，對一些展現型的、交互體驗要求不那麼高的產品，能夠採用這種h5技術處理。你們若是在驗證市場階段，能夠採用相似技術快速作一個可用產品出來。

此外說一下蘋果app上架的問題。我是利用虛擬機安裝了一個黑蘋果系統，而後裝相應工具，把app上傳到蘋果商店去。關於如何開通蘋果開發者帳號，如何在虛擬機安裝蘋果系統，這個你能夠自行搜索。

用戶反饋和社區運營

一開始，用戶反饋消耗了我很多精力。敢情本身成爲一個客服了。後來我開始作了一些改變，基本把本身從這些反饋中抽身出來了。

首先我分開了官網在線版和開源版的反饋，開源版的反饋統一到github（gitbug的使用門檻能過濾掉一些很是新的新手，避免新手問題），在線版的反饋統一發郵箱。有功能或者bug要改，我先記在團隊看板。而對於一些常見問題，我整理好了文檔，和一些固定的回覆術語。另外我也開了三個qq羣，供showdoc使用者自身交流。不過我要提的一點是，千萬別試圖回答qq羣裏提的每個問題，會把人逼瘋的。因此我更改了羣公告，改寫了羣定位，將qq羣定位爲用戶自行交流的地方。讓熱心用戶去回答新手在使用showdoc時遇到的問題。而我則只須要很偶爾看一下。須要官方的支持仍是讓用戶走github或者郵件通道。

不過值得一提的是，我這種運營思路是不適合全部團隊的。我是人力有限，效率優先，因此過濾了不少不太必要的反饋。假如說有很足夠的人力，我倒建議能夠多花時間幫助用戶解決問題，既擴大用戶量，又提升產品口碑。