Hello，我是雙生日記的 Founder & Developer Airing。該項目的小程序端獲得了 2018 C4—— 微信小程序應用開發賽的一等奖，而 iOS 端則獲得了 2018 C4—— 移動應用創新賽的一等奖，目前累計註冊用戶已達 1 萬 +，並仍在不斷開發維護中～
本文將簡要概括我們團隊在產品的整個研發流程中的所做的工作，更側重於介紹產品研發與團隊管理的方法。
我將整個產品的研發分為以下四步：
- 立項
- 設計
- 開發
- 維護
可以看到，以上四步形成了項目流程的閉環，使得產品能夠良性發展。接下來我來具體談談這四步工作的內容。
1. 立項#
項目立項是所有環節最開始的部分，我覺得也是最重要的部分，它的工作內容類似於 “產品經理” 的職責。雖然我是 Founder，但產品的探討還是與大家共同完成的。具體而言，這個環節有兩個內容：
- 產品腦暴
- 文檔整理
1.1 產品腦暴#
首先，我會先在團隊中提出我的想法，並創建一個討論區供大家討論。我們是一個非常大的興趣團隊，雖然參與雙生研發的只有寥寥三人，但是在產品腦暴的時候，團隊的成員都提出了各自的見解與建議。例如，下圖是我們在團隊研發中討論的內容。
這裡我們團隊用的是產品是 “語雀”，當然工具是隨意的，用騰訊文檔我覺得也非常方便，重要的是一定要形成電子版記錄材料，如果只是在微信群裡討論或者線下簡單聊聊，那討論了、忘記了，那就相當低效，約等於沒有討論。
1.2 文檔整理#
第二步，整理腦暴的文檔並撰寫相關的研發文檔，具體來說，包括但不限於：
- 需求文檔
- 產品文檔
- 模型文檔
- 接口文檔
PS. 這是我們團隊的文檔庫，僅供參考：零熊 | 語雀
2. 設計#
設計工具我們用的 Sketch，但不會把源文件直接發給研發同學，因為正版 Sketch 挺貴的，而且只支持 mac 系統。這裡我們使用的工具是藍湖，開始用的也是語雀的畫板，但發現實在是太難用了… 另外，在藍湖中的設計稿是可以分享的，並且邀請團隊裡的同學進行評點。
設計稿的內容具體包括：
- 規範
- 原型
- UI
- 切圖
規範重點是色彩規範、組件規範、和字體規範。原型更多的是交互說明，這裡我們只是用批註的方式在 ui 上詳細說明了一下交互，但如果直接用 flinto 去做也是可以的。flinto 的好處是更加直觀，但是開發人員不一定能 get 到設計同學的全部內容。
3. 開發#
本部分分享的是產品研發的核心環節：項目開發。本環節我分享的內容會稍微多一些，但也略微零散，主要包含三個內容：
- 規劃記錄
- 開發工具
- 建議事項
3.1 規劃記錄#
在開發之前，我習慣於自己先列一個 todolist 去羅列出項目中的各個需求點或技術點，從整體上會有一個直觀的感受，也方便我去安排和規劃自己的開發任務。這裡我使用的工具是 Notion，我先按照重要的模塊把產品分割成了 8 個部分，然後再在每個部分裡寫各自的 todolist，以免單文件 todolist 過長。
當然，todolist 不單單記錄待辦事項而已，它更多的是承擔一個開發日記的作用。我個人傾向於把開發中遇到的難點問題及解決方法，或者用到的資源順手記錄下來。我認為開發是一個學習和成長的過程，而不僅僅只是完成業務需求。 隨手記錄是方便日後整理為博客或者再遇到類似的問題可以快速定位，若不記錄則很容易忘記。因此，做開發日記對學習的成效是非常大的。
3.2 開發工具#
針對微信小程序開發，我建議對開發很熟悉的同學可以嘗試去使用 VS Code + 擴展 + 真機的模式進行開發，個人覺得這套流程既高效又不會出錯。“高效” 是 VS Code 自身的高效，而 “出錯” 指的則是模擬器有時候效果與真機不同。
這裡順便安利一下我自己的 VS Code 配置：
我喜歡把資源管理器放在右邊，有兩個原因：一是左邊是人的注意區，故應該放代碼編輯器；二是我隨時按 Cmd + B 可以隱藏資源管理器而同時不改變編輯器的位置，如果放左邊，隱藏的時候編輯器會有一個位移，眼睛會很不舒服。
對於擴展，我這裡用了幾個比較有意思的：
- Color Highlight：顏色值高亮可視化為顏色本身，方便前端樣式開發
- TODO Highlight：高亮 TODO 與 FIXME
- miniapp：小程序標籤與屬性自動補全
- Bracket Pair Colorizer：括號著色配對，這個特別方便。
- Image preview：方便在代碼裡預覽 uri 上的圖片，我是用來看看自己資源路徑有沒有引錯。
- REST Client：HTTP 測試，方便開發、分享與 mock。
主題我用的是 Winter is Coming Theme + Material Icon Theme，我個人覺得黑色默認也非常好看。
3.3 注意事項#
如果是協同開發我推薦搭配 Git History + Eslint 插件，當然如果自己開發，也免不了 Eslint。Git Commit 規範我們用的是這套： Commit 提交規範
開發的時候也別忘記埋點，做一些打點統計，需要打點的地方根據項目需要檢測的內容來定。如 PV、UV 這些小程序自帶幫你統計了你可以不用打，但其他項目還是要統計的，或者直接規劃好 Nginx 的日誌，再對日誌做分析也是 ok 的～
如果前後端分離開發，前端同學可以自己接 mockjs 做一套符合接口文檔規範的 mock 接口。
4. 維護#
對於用戶的反饋，我們智能篩選後自動提交到 github issue，再針對 issue 進行 label 和優先級分配。這是我們項目開源的主地址：oh-bear/2life。
可以看到 issue 是比較雜亂的，所以還需要 github 的 project 去做一個任務畫板。
by the way，安利一下小工具Devhub，可以很方便的檢測自己負責項目的 issue。
針對這些 issue，可以做一個階段性的文檔，回歸到 “立項” 步驟，進行下一個小版本的開發。
可以發現，我始終沒有去選擇使用甘特圖軟件，雖然甘特圖更加直觀，但是我不太喜歡把任務排的滿滿的、緊緊的，這樣會不自覺地产生工作壓力。最重要的是，我們畢竟不是工作嘛，只是一個興趣開發，所以還是遵循自己的喜好來便好～
好了，這次的分享就到這裡。我是 Airing，我的個人博客是：https://me.ursb.me，歡迎大家來訪交流～