前言

我開發(fā)的開源文檔工具在github上上升到了5300+的star ，受到了部分開發(fā)者的歡迎。于是便想寫與大家分享一下我在整個(gè)創(chuàng)作過程中所用到的技術(shù)以及相關(guān)技能。

任務(wù)管理

無論是做自己規(guī)劃的產(chǎn)品功能，還是做用戶反饋過來的bug，最終都需要把這些點(diǎn)細(xì)化成一個(gè)個(gè)單獨(dú)的小任務(wù)，串聯(lián)執(zhí)行（畢竟自己是單個(gè)人力）。在這點(diǎn)上，我主要是利用團(tuán)隊(duì)看板來實(shí)現(xiàn)我的任務(wù)管理。團(tuán)隊(duì)看板工具有好多，搜索一下就好，我個(gè)人目前在用tower.im

看板上我新建五個(gè)清單，分別是“在做”、“要做-高優(yōu)先級(jí)”、“要做-低優(yōu)先級(jí)”、“待定”、“遺留問題”，我這樣分類是有技巧的。首先，它有優(yōu)先級(jí)劃分，保證先做重要的事。其次，它有狀態(tài)管理，方便我隨時(shí)中斷某個(gè)任務(wù)，過一段時(shí)間再回來繼續(xù)任務(wù)。同時(shí)，它也能應(yīng)對(duì)新任務(wù)——比如說新需求進(jìn)來，我先放在“待定”，等有空了再分配到其他清單去。最后，它還有“遺留問題”清單，可以讓我不在某個(gè)“疑難雜癥”上卡住太多時(shí)間，快速推進(jìn)下一個(gè)任務(wù)。

本地開發(fā)

用Linux或者M(jìn)AC會(huì)非常方便開發(fā)、搭建測(cè)試環(huán)境等，對(duì)開發(fā)者的方便是毋庸置疑的。但是電腦有時(shí)候需要玩游戲，需要裝一些專業(yè)大型軟件。從兼容性和廣泛性的角度來考慮，我個(gè)人還是使用windows系統(tǒng)。在win上，我使用的是Vagrant + virtualbox這個(gè)組合。Vagrant是一套工具，幫助你快速在win系統(tǒng)上，利用virtualbox搭建起虛擬機(jī)，從而方便使用linux或者M(jìn)AC(比如上架蘋果app的時(shí)候我需要MAC虛擬機(jī))。關(guān)于這點(diǎn)，可以參考我?guī)啄昵皩懙囊黄坛蹋篵log.star7th.com/2015/06/1538.html

代碼管理

我用git作為代碼版本管理工具，同時(shí)使用tortoisegit進(jìn)行可視化操作。
說一下我是怎么維護(hù)官網(wǎng)在線版showdoc和開源版showdoc的。我在自己的服務(wù)器安裝一個(gè)私有版的gogs作為私有g(shù)it管理平臺(tái)。功能開發(fā)好了，我再推送到github上去。官網(wǎng)版和開源版一開始是同一個(gè)倉(cāng)庫里的不同分支。后面它們的差異（尤其是后端代碼的差異）越來越大，所以我干脆把它們分成兩個(gè)不同的倉(cāng)庫了。做開發(fā)的時(shí)候，我一般是現(xiàn)在官網(wǎng)版上做開發(fā)以及測(cè)試驗(yàn)證，然后再用tortoisegit的代碼修改差異比較功能，把功能遷移到開源版去。

說一下分支管理策略。我至少建立兩個(gè)分支——主分支和開發(fā)分支。新功能會(huì)在開發(fā)分支做，驗(yàn)證好了再合并到主分支來。用開發(fā)分支的時(shí)候也有技巧。比如說，一個(gè)大的功能可以基于開發(fā)分支再新開一個(gè)分支去做。例如我今天想做A功能，那就在A分支上操作。但是A功能遇到瓶頸了，這會(huì)兒我暫時(shí)沒精力去找bug，所以此時(shí)我可以再基于開發(fā)分支開啟B分支，繼續(xù)做B功能。這很重要，因?yàn)樵谌肆τ邢薜那闆r下，我做什么事情都是串聯(lián)的，同一時(shí)刻只能做一件事。這樣的策略有利于保證自己隨時(shí)中斷、隨時(shí)上手任務(wù)，靈活地安排不同的時(shí)間去處理容易的或者棘手的問題。這個(gè)過程也需要配合上面說到的團(tuán)隊(duì)看板使用。中斷前要記錄好進(jìn)度，方便自己隨時(shí)恢復(fù)工作。

shell自動(dòng)化腳本

我為showdo寫了三個(gè)shell自動(dòng)化腳本。其作用分別是自動(dòng)化部署showdoc，自動(dòng)生成api文檔到showdoc，自動(dòng)生成數(shù)據(jù)字典到showdoc。之所以選擇shell而不是其他腳本語言（如python），是因?yàn)閟hell基本可以運(yùn)行在絕大部分linux上，部分運(yùn)行到win上（需要安裝工具），兼容性超好，依賴非常少。根據(jù)反饋，受到的好評(píng)比負(fù)面評(píng)論多得多。自動(dòng)化腳本大大節(jié)省了使用者安裝環(huán)境的麻煩，降低了showdoc的使用門檻。showdoc大部分的用戶不是php開發(fā)者，要他們安裝php環(huán)境還是挺折騰的。有了一鍵腳本，他們用得方便，我也省心，不需要在解決新手反饋上花太多功夫。這個(gè)方法是具有普適性的，并且語言無關(guān)（因?yàn)橐绘I腳本使用docker跑服務(wù)）。是可以大量應(yīng)用到開源項(xiàng)目中，非常有利于開源項(xiàng)目的代碼分發(fā)。

順便強(qiáng)調(diào)一下，做web應(yīng)用開發(fā)的人，尤其需要克服一下對(duì)shell腳本的疏遠(yuǎn)感。我以前以web開發(fā)為主的時(shí)候就會(huì)潛意識(shí)地疏遠(yuǎn)shell。在騰訊的時(shí)候向另一個(gè)技術(shù)棧的同事請(qǐng)教了下，發(fā)現(xiàn)其實(shí)還是蠻簡(jiǎn)單的。只是因?yàn)樽约哼^去心理上的疏遠(yuǎn)感導(dǎo)致自己沒想過要去寫shell。跨過這個(gè)心理檻，就會(huì)擴(kuò)展自身的能力邊界，寫起來跟其他語言沒有太多區(qū)別，僅僅是需要多搜索查詢下語法而已。

后端開發(fā)

可能是因?yàn)閟howdoc僅是一個(gè)小產(chǎn)品，涉及到的后臺(tái)邏輯并不復(fù)雜，所以我在開發(fā)后端花的時(shí)間不多，基本上都是CRUD，對(duì)數(shù)據(jù)庫進(jìn)行增刪改查操作。需要多動(dòng)點(diǎn)腦力的地方在于團(tuán)隊(duì)管理功能，新建多幾張數(shù)據(jù)表聯(lián)合實(shí)現(xiàn)精細(xì)化權(quán)限控制。

showdoc后端主要采用的是國(guó)產(chǎn)框架thinkPHP。這個(gè)框架有好也有不好。不好的地方在于它的框架約定、生態(tài)共享比較一般，好的地方在于它可以快速擼出一個(gè)東西來，而且兼容性還可以。這是四年前我剛開發(fā)showdoc時(shí)的決定，后來也懶得換框架重寫了，所以沿用至今。技術(shù)是相對(duì)落后了一些，但是也勝在兼容性好，可以兼容老的php環(huán)境和一些老的服務(wù)器。這個(gè)還是挺重要的，因?yàn)閟howdoc是開發(fā)輔助性質(zhì)的工具，協(xié)助寫文檔。兼容性越好就越容易被各種各樣的群體接受。個(gè)人覺得這一點(diǎn)比用各種先進(jìn)技術(shù)要更實(shí)用一些。當(dāng)然了，如果是現(xiàn)在新開發(fā)其他項(xiàng)目，我應(yīng)該會(huì)使用laravel，或者NodeJS寫的eggjs。

前端開發(fā)和UI

我在前端開發(fā)上花費(fèi)的時(shí)間比后端開發(fā)時(shí)間多很多?？赡苁且?yàn)檫@是個(gè)體驗(yàn)型產(chǎn)品，需要把前端體驗(yàn)做好。起步一個(gè)產(chǎn)品的前端頁面時(shí)候，我建議一定要選好一個(gè)UI框架。比如我選擇的是ElementUI做showdoc，而runapi則使用museUI（runapi是輔助showdoc用的一個(gè)在線api測(cè)試工具）。

showdoc用的編輯器是editor.md，是幾年前的產(chǎn)品。雖然說它代碼組織方式可能有點(diǎn)落后，且原作者似乎有放棄維護(hù)的趨勢(shì)。但我覺得它功能強(qiáng)大且簡(jiǎn)潔美觀，所以我花了時(shí)間將它封裝成了vue組件，并且修改其源碼增加了安全性。

項(xiàng)目拖拽和頁面排序我用的是vue組件vuedraggable，還蠻好用的。以后有拖拽的需求我估計(jì)還是用它。

圖標(biāo)設(shè)計(jì)方面，可以使用UI框架內(nèi)置的字體圖標(biāo)，也可以用阿里媽媽的矢量圖標(biāo)庫。或者自己使用Iconion進(jìn)行圖標(biāo)設(shè)計(jì)。這里我強(qiáng)調(diào)一下Iconion。這個(gè)工具可以非常簡(jiǎn)單快捷地使用一些預(yù)定的圖案和背景，組合成一個(gè)快速可用的產(chǎn)品圖標(biāo)。showdc的產(chǎn)品圖標(biāo)就是這樣制作的，快速省時(shí)地做到媲美專業(yè)的效果。如果以后把產(chǎn)品做大了，可以考慮請(qǐng)?jiān)O(shè)計(jì)師設(shè)計(jì)。但在項(xiàng)目前期，用Iconion就夠了。

在這里要提一下前端技能的重要性。雖然說UI框架以及相應(yīng)的工具能夠幫助你節(jié)省很多時(shí)間。但如果想做好一個(gè)產(chǎn)品的體驗(yàn)，那么其涉及到的UI和交互可能超出框架自帶的范圍。因此自己必須學(xué)會(huì)使用原生css，會(huì)js交互，會(huì)封裝組件。而且，前端技能跟下面要說的app多端開發(fā)也有幫助。

app多端開發(fā)

關(guān)于移動(dòng)app產(chǎn)品原型設(shè)計(jì)，我很建議使用“墨刀”來做簡(jiǎn)單的原型規(guī)劃。有了一個(gè)可視化的原型，真的能節(jié)省很多大腦時(shí)間，讓你在開發(fā)階段的時(shí)候可以專注代碼，而不需要寫一下代碼，又回頭思考下一步做什么功能，這樣的來回切換相當(dāng)?shù)⒄`效率。

app開發(fā)我用的是uniapp，使用html5等前端技術(shù)把代碼封裝成手機(jī)本地app，包括安卓app、蘋果app，甚至小程序。這種技術(shù)幾年前就有了，但是性能一直不溫不火。2019年的時(shí)候我看到了這塊發(fā)展得還是可以的。所以就產(chǎn)生了做showdoc app端的想法。不過由于showdoc重在pc web端，手機(jī)只是起到輔助作用，所以我沒有很精心去做。大概把web版簡(jiǎn)化一下，復(fù)用一些組件，重寫下前端，然后就上線了。順便說一下，我做得比較精細(xì)化的app是時(shí)光樹洞（blog.star7th.com/2019/09/2380.html) ，這款app的UI就花了點(diǎn)心思。

如果要讓我評(píng)價(jià)這種混合型app和原生app，我會(huì)說，肯定原生app最好。只是出于成本和人力的考慮，對(duì)一些展示型的、交互體驗(yàn)要求不那么高的產(chǎn)品，可以采用這種h5技術(shù)處理。大家如果在驗(yàn)證市場(chǎng)階段，可以采用類似技術(shù)快速做一個(gè)可用產(chǎn)品出來。

此外說一下蘋果app上架的問題。我是利用虛擬機(jī)安裝了一個(gè)黑蘋果系統(tǒng)，然后裝相應(yīng)工具，把a(bǔ)pp上傳到蘋果商店去。關(guān)于如何開通蘋果開發(fā)者賬號(hào)，如何在虛擬機(jī)安裝蘋果系統(tǒng)，這個(gè)你可以自行搜索。

用戶反饋和社區(qū)運(yùn)營(yíng)

一開始，用戶反饋消耗了我不少精力。敢情自己成為一個(gè)客服了。后來我開始做了一些改變，基本把自己從這些反饋中抽身出來了。

首先我分開了官網(wǎng)在線版和開源版的反饋，開源版的反饋統(tǒng)一到github（gitbug的使用門檻能過濾掉一些非常新的新手，避免新手問題），在線版的反饋統(tǒng)一發(fā)郵箱。有功能或者bug要改，我先記在團(tuán)隊(duì)看板。而對(duì)于一些常見問題，我整理好了文檔，和一些固定的回復(fù)術(shù)語。另外我也開了三個(gè)qq群，供showdoc使用者自身交流。不過我要提的一點(diǎn)是，千萬別試圖回答qq群里提的每一個(gè)問題，會(huì)把人逼瘋的。所以我更改了群公告，改寫了群定位，將qq群定位為用戶自行交流的地方。讓熱心用戶去回答新手在使用showdoc時(shí)遇到的問題。而我則只需要很偶爾看一下。需要官方的支持還是讓用戶走github或者郵件通道。

不過值得一提的是，我這種運(yùn)營(yíng)思路是不適合所有團(tuán)隊(duì)的。我是人力有限，效率優(yōu)先，所以過濾了很多不太必要的反饋。假如說有很足夠的人力，我倒建議可以多花時(shí)間幫助用戶解決問題，既擴(kuò)大用戶量，又提高產(chǎn)品口碑。