Valo Documentation
首頁
開發設置
專案結構
登入前單元
登入後單元
聊天對話單元
聊天系統
群組系統
認證
部署
故障排除
首頁
開發設置
專案結構
登入前單元
登入後單元
聊天對話單元
聊天系統
群組系統
認證
部署
故障排除
  • 專案文檔

    • 開發環境設置指南
    • 專案資料夾結構說明
    • - 聊天功能核心
    • - 群組目錄
    • 身份驗證
    • 登入前的單元
    • 登入後的單元
    • 聊天對話單元
    • 部署指南
    • 常見問題排解
    • 專案故事
    • 最初的那些痛

專案時間軸

2025 年 03 月

當時專案初步啟動,當時與 R 哥團隊配合,透過 R 哥團隊的資深 APP 開發經驗,希望能快速建立原型,以下為過程:

  1. 啟動會議開始

  2. 討論該產品方向、合作模式

    • R 哥團隊負責前台
    • Dash 團隊負責後台
  3. 中間規劃時,有一度朝著 自建版本,後來經過 Stanley 提醒使用 Agora 來作為核心聊天架構。

  4. survey Agora 過程出現 分工分歧。

    • R 哥團隊希望全墊API (除了 message ),保持架構整潔、專業分工
    • 我希望 部分墊API,針對特殊需求,以求 MVP 原型為優先,後續迭代。
  5. 當時答應以 R 哥 全墊API 為方向。

  6. 後續 3 月中旬,有交付一版 Android 原型。

    • 當時有內部討論 R哥團隊,可能無法撥大量能在 Valo 身上,可能對於開發、專案角度上,更不好控管
  7. boheng survey Flutter 開發,接手 APP 開發方向,後續在 3 月底開工。

boheng:

規劃核心的角度:

  1. 需要快速建立 原型 產品
  2. 方便雙方 開發

以 Agora 為基底,當時有兩個方案可以走:

  1. 任何 API 都需要墊 API,都後端包裝過一層,能滿足特殊需求
  2. 只針對需要 特殊需求 而開立 API,其他都給 APP 串接 Agora SDK

方案 1 的角度:

  • 優勢: 乾淨的系統架構,所有事情&業務都包裝後端,後端再去墊 Agora。
  • 劣勢:前期快速可能就無法滿足,需要等後端完全開發好才能進入下階段。

方案 2 的角度:

  • 優勢: 前台與後台分工進行,前台針對 Agora SDK文檔 實現功能,後端針對 無法滿足的需求提出 API。
  • 劣勢: 前端複雜度會提高很多,不是一個好架構。
    • debug 劣勢?:面對 Agora SDK文檔 與 全墊 API Server,我的角度,當時反而比較能相信Agora SDK文檔

產品開發提醒

做產品時,開發們要時刻記住現況交付的價值、問題對象、個人程度、團隊資源,當下你面臨的周遭資源,去決策當下要做的事情,那就是合適的!

boheng 的開發心路歷程

過往開發時,會在開發時程與程式品質間做權衡,前期面臨到此情況,通常兩難,而當時的時空上,需要做出初步的 prototype,勢必犧牲了許多品質,但經由後續的產品測試與專案管理者,確認取得確定感後,2025 年 7 月後的思考模式會多加一些維持穩定的改善方式、維持功能平衡、收納競品的 idea,keep going!

最後更新: 2025/8/21 上午10:09
貢獻者: boheng