原文首發在我的部落格，歡迎關注~
大概半年前（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~