前言
大家好，我是開源文件工具showdoc的作者。目前showdoc在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或者郵件通道。
不過值得一提的是，我這種運營思路是不適合所有團隊的。我是人力有限，效率優先，所以過濾了很多不太必要的反饋。假如說有很足夠的人力，我倒建議可以多花時間幫助使用者解決問題，既擴大使用者量，又提高產品口碑。
後記
先講這麼多。其實還有很多東西可寫，上面很多點也可以細化成一篇篇獨立的文章。先看看使用者反響吧。如果沒人看，那就這樣吧。如果有不少人覺得有幫助，我再寫點什麼，或者擴充上面的小點成獨立文章，發出來或者寫到自己的部落格上。
本作品採用《CC 協議》，轉載必須註明作者和本文連結