PicGo的star數破1000的心路歷程

原文首發在個人博客，歡迎關注~

大概半年前（2017年11月28日）我在GitHub上開源了一個基於electron-vue的開源桌面應用PicGo。其出發點是爲了改善我在寫博客的時候貼圖困難的問題。在通過了半年的持續維護和一些宣傳（《PicGo：基於 Electron 的圖片上傳工具》、《圖牀上傳工具PicGo v1.5更新：支持騰訊雲COSv5版本、支持GitHub圖牀、支持上傳前重命名文件等等》等等）後，6月12日，它的star數也終於突破了1000的關卡。在這過程當中我也學習了很多東西。在和你們交流的過程當中，我才發現原來你們都有着這些需求，才發現我一開始的實現思路並不是到位等等。謹以此文記錄與PicGo有關的個人心路歷程。

趕巧前不久也有一個開發者chyingp的開源項目破了1000star，也有着相似的文章，祝賀！

項目誕生

我之前寫博客的時候，因爲一開始用的是七牛的圖牀，因此遇到要在markdown裏貼圖的時候就必須登陸七牛，而後手動上傳圖片，再找到按鈕來複制連接，而後複製到markdown裏。要在markdown裏顯示一張圖片我得通過上述4個步驟。

我本身的筆記本用的是mac，因此我就接觸到了一款叫作iPic的圖牀神器。在用它的時候我也知道了微博圖牀。iPic的功能和體驗真的特別好。不過若是須要使用七牛等其餘圖牀的時候，我就須要付費了。其實若是iPic支持windows的話，我可能就真的去付費了。（由於實驗室的電腦是windows，因此我平時在實驗室裏得用windows來寫東西）。僅爲mac一個平臺付費我有點不能接受。

因而我就在想可否我本身寫一個工具來簡化個人上傳圖片的流程呢，這個應用能夠實現拖拽圖片就上傳，而後上傳完自動複製連接到剪貼板裏，我就只要粘貼到markdown裏就行了。一開始想用swift寫mac的應用，用C#寫windows的應用。後來發現工做量不只大，並且學習成本也很高。因而最後仍是選擇投入electron的懷抱。

一開始不選擇electron主要是由於個人印象中electron的應用體積都挺大的（100MB以上），因此感受體積可能有點不友好。不事後來我在用了electron-vue打包出來後發現體積是能夠接受的範圍（mac端大概50M，windows端大概38M），因而就決定用它來寫了。用electron-vue的主要緣由是我寫vue比較多，想要學習成本低一些，這樣開發只要學electron的部分就行了。

說幹就幹，在去年年末（11月下旬）我開始寫這個應用。

項目發佈

文末會給出electron-vue開發的系列經驗教程

通過20多天的間斷性地開發，我在12月12號發佈了1.0.0版本。因爲一開始是在mac上開發的，因此1.0.0版本也只支持了macOS。一開始支持的圖牀也很少，只支持了微博和七牛兩個圖牀。

1.0.0版本的截圖以下：

基本實現了我預期的功能，相似iPic可以經過拖拽到頂部欄圖標上傳。而且爲了從此支持windows平臺（windows平臺的任務欄圖標不支持拖拽事件），我就作了一個主窗口，在主窗口裏也有拖拽上傳的區域。由於有了主窗口，我就順便把圖牀的配置也放到了主窗口裏。

應用作出來了，我也想讓更多的人用到。因而我在北郵人論壇、cnode、v2ex還有掘金都發了文章。不過一開始看到的人寥寥無幾，發了文章也沒多少人看到和使用。後來我在少數派上發了一樣的文章，意外地被推薦到了首頁。

此次的契機讓PicGo意外地有了些用戶和star數。在跟使用者交流的過程當中我也開始逐步往PicGo里加功能和修復bug。在1月10日的時候，PicGo更新v1.3.1版本支持了windows系統。

由於開始有用戶了，PicGo早期確實存在着很多功能的缺失，好比快捷鍵上傳，其餘經常使用圖牀的缺失等等。因此那時候是PicGo迭代最快的一段時間。經過你們在issue裏的反饋，我也在不斷打磨PicGo。能夠看到截止6月14日，已經有61個被關閉的issue了。

項目改進

用戶體驗這個東西真的並非開發者在開發的時候可以立馬就想到的。這點在開發PicGo上我體會很深。

好比增長快捷鍵上傳這個功能，我一開始以爲自定義快捷鍵寫起來比較麻煩，乾脆我定一個你們基本用不到的快捷鍵吧。因而我默認給了一個【command/ctrl+shift+p】的快捷鍵。我本身用的時候沒有什麼問題。結果有人給我反饋說，快捷鍵跟某某某軟件衝突了，可否給一個快捷鍵自定義的功能。這是我沒法迴避的一個問題。因而我就開始去學習如何加入自定義快捷鍵。並在不久以後實現了個這個功能。

好比自定義連接格式的問題。我一開始給了你們4種複製連接的格式，分別是markdown、HTML、URL、UBB。原本覺得這4種格式就足夠你們平時使用了。後來有人提了一個issue，問PicGo可否自定義連接格式，由於他想基於HTML增長一些屬性，好比大小居中等。我以爲這個使用場景確實是有的，因而我便在後來的某個提交裏實現了這個功能。

固然並非你們有這個需求我就必定要作。還有一些需求我以爲並不符合我對於PicGo的定位的，那麼我就會給予回絕。好比後期可否支持上傳視頻文件？，因爲PicGo的開發初衷只針對圖片，因此在流程上（圖片->base64）就不容許上傳視頻文件。因而我拒絕了這個需求。

還有一個對我以及PicGo這個項目影響深遠的issue，ZetaoYang提出了一個想法：

這個建議改變了我對PicGo開發的後續想法。我思考了很久，發現確實一步步增長默認的圖牀支持是不長遠的。一個是重複性勞動太多（圖牀上傳除了協議和加密方式不一樣以外，接收文件，轉成base64和最後上傳成功後存到本地的流程是同樣的），一個是無止盡的圖牀支持其實也不該該。相比之下，把PicGo作成一個Core+Plugin模式的應用會更好。其中Core的部分能夠單獨只作圖片接收和轉碼，並預留一些生命週期，供上傳過程當中不一樣的需求來調用。Core的部分能夠單獨發佈成一個npm包。Plugin能夠實現接入Core的生命週期，能夠實現本身的上傳邏輯，能夠實現圖片壓縮、加水印等等其餘功能。而PicGo只是在Core+Plugin的基礎上套了一層electron的皮方便普通用戶使用，而Core和Plugin能夠獨立拆出方便開發者使用和開發。這個也是PicGo的2.0版本將要作的事。

總結

在開發PicGo的過程當中我也深入瞭解到，寫一個DEMO不難，給這個DEMO注入你本身的思想和靈魂是難的。PicGo從一個一開始只是我想簡化上傳圖片流程的玩具應用，發展到如今，總下載量突破7000次，已是很多用戶的效率工具而言，其實一路走來也並不容易。如今你們對用戶體驗的要求愈來愈高，若是隻沉醉在本身的DEMO裏沒法自拔，只會被更好的產品所淘汰。

開發PicGo也是一件很開心的事。你們給予個人讚揚和感謝，都是給我繼續開發的動力。而我也發現愈來愈多的文章裏，都提到了PicGo。以下：

• 《老司機的神兵利器-效率工具》
• 《PicGo 強大的免費圖牀工具》
• 《PicGo：開源的圖片管理工具》
• 《圖牀神器PicGo》
• 《提高生活品質——我的效率工具與資訊網站推薦》
• 《7 款 Windows 國產軟件推薦》

我想，獲得大家的承認，把它寫進大家的文章，這是對我最大的確定，這個比star數更令我感到開心。

我在開發PicGo的過程當中，也寫了一個系列文章Electron-vue開發實戰。若是你也想學習electron或者electron-vue的開發的話，但願個人文章可以給你帶來幫助。若是你以前沒有據說過PicGo，那麼不妨試試；若是你以爲它挺好用的，不妨點個star~