第八屆 CMoney 專業分享暨招募說明會－我們如何用 PAGEs 打造上百支 Apps

2025 年 4 月 25 日的第八屆 CMoney 專業分享暨人才招募說明會，我們很榮幸能與 Android Taipei 開發者社群共同舉辦，本次主題為 PAGEs 系統的設計與技術架構，我們將揭秘PAGEs 具體是如何協助 CMoney 模組化開發數百支應用，大幅提升工程團隊的開發效率。

PAGEs 系統的需求背景

CMoney 一直致力於「幫助每個人做好人生投資」，無論是在金融、消費還是社群領域，我們都希望能夠透過創新的工具和平台，提升每個人的生活品質。這份使命促使公司不僅要做出好的產品，更要不斷嘗試提升開發效率與系統架構穩定性。

在開發初期，CMoney 的每一個 App 都是獨立的專案，但隨著業務的擴展，工程開發團隊開始面臨到規模化開發的挑戰，尤其是在同時應對數百款 App 的開發與維護時，每個專案都面臨著「需開發重複邏輯的功能」以及「需要同時維護和修復相似功能」的問題。舉例來說，當一個 App 中某個功能出現 bug 時，開發人員需要在所有其他相似的 App 中進行相同的修復工作，卻無法實現代碼重用，這無疑增加了開發的成本與時間。

為了解決開發規模化與維護上的困難，CMoney 使用了 PAGEs 系統，目標解決「如何開發穩定、可讀性高且易於維護的元件」這一大挑戰。

 

引入「共享模組」的概念

CMoney 引入了共用模組（shared module）的概念，將一些不同 App 之間通用的功能模塊從獨立的專案中抽取出來，作為單獨的模組進行管理和維護。這樣，當某個功能出現問題時，只需在共享模組中進行修復，所有使用該模組的 App 都能自動受益，有效降低維護成本和重工問題。

然而，共用模組所拆分的顆粒度，仍然無法完全解決不同 App 間高客製化需求所帶來的挑戰。許多 App 在功能上存在較大差異，尤其是面對大量財經作者和老師的客製化需求，既有的共用模組仍無法充分應對。

因此，團隊決定進一步降低模組化的顆粒度，將 App 界面上的常用工具（如股票列表、K 線圖等）開發成可重覆使用的「UI 元件」來提升複用性以及客製化程度。

 

PAGEs 系統的核心設計

可組合性與可配置性

在 PAGEs 系統的設計中，最核心的概念是「可組合（composable）」與「可設定（configurable）」。每一個 UI 元件（如圖表、列表、按鈕等）都能被任意組合，PM (Product Manager) 可以根據需求自行將各別元件組合成一支完整的 App，並且對每個元件進行設定，以滿足客製化需求。

例如，某些圖表可能需要顯示不同的數值範圍或顏色，而 PM 只需要通過簡單的設定，便可以達到預期的效果，且完全不需要再為常用元件寫任何程式，實現了 No-code 開發。

這種設計方式讓 CMoney 能夠在應對數百個 App 的開發與維護時，保持了高度的靈活性和可擴展性。每當有新功能或新需求時，PM 只需要在元件庫中選擇元件進行組裝，必要時再請工程師開發新的元件，從而迅速生成符合需求的 App，避免了重複性工作。

將開發流程自動化

PAGEs 系統的另一大亮點在於其開發流程的自動化。從需求理解、技術規劃到開發實作，再到測試和驗收，整個流程都可以使用 PAGEs 系統快速完成。首先，PM 只需要通過 GUI 界面選擇所需的元件並進行設定，系統會自動生成 App 的 Blueprint；接著，將 Blueprint 輸入自動化工具即可產生一支完整的 App。最終的 App 會自動上架到 Firebase 或 Google Play，整個流程實現端到端自動化。

對於一個新簽約 CMoney 的財經作者來說，如果他想製作符合他投資邏輯的 App，他所需要的大部分元件如果已存在於元件庫中，就不需要重新進行開發，只需要透過簡單的設定，PM 就可以快速生成專屬的 App。這種高效的開發方式，對於處理大量客製化需求的情況尤為重要。

 

團隊協作：跨部門合作與技術規劃

PAGEs 系統的開發和運作非常依賴團隊的高效協作。在需求理解階段中，PM、RD（工程團隊）和 UI 設計師會共同參與討論，確定每個元件的設計和功能要求。

開發 App 時，CMoney 團隊會特別關注兩個方面：意義可行性和技術可行性。意義可行性是指這個需求是否具有實際價值，是否能夠解決現有問題；技術可行性則是指現有的技術框架能否支持這一需求。

此外，在進入開發階段之前，RD 與 PM 會共同進行「技術規劃」，並在白板上畫出開發結構圖，分析每個元件之間的交互和數據流，前期的精細規劃有助於避免後期開發中出現的需求與產出不一致問題，確保最終的產品能夠符合設計要求。

 

元件的 Design Review 機制：可信度加權

CMoney 的 PAGEs 團隊在正式開發前，會先設計元件的介面。 為了確保新設計的元件符合 PAGEs 系統的設計原則，我們實行了一種獨特的「可信度加權」的 Design Review 機制。這一機制的核心思想來自 Ray Dalio 的《Principles》一書，根據每位團隊成員的經驗和專業能力對其建議進行加權，這樣可以確保高經驗的工程師提出的建議獲得更多重視，從而提高決策的質量。

在 Design Review 過程中，每個成員會根據核心評定標準，對元件設計進行打分，這些標準包括元件是否符合需求、簡潔性、可擴充性、是否符合 convention 等，每個成員的評價分數將根據其可信度進行加權，從而得出最終的評價結果。

 

開發過程中的 Code Review 機制

PAGEs 團隊在開發過程中的 Code Review，會將重點放在五個層級（P1 到 P5）。例如，P1 層級最重要，專注於的元件的 interface 設計，P2 代表功能實作細節；而 P5 層級則可能是與程式碼風格、格式等較為次要的內容。透過這種分級機制，能夠將 issues 有效進行分級，並確保能在時限內將相對重要的 issues 處理完畢。

 

結論

在本次的 CMoney 專業分享暨招募說明會中，我們介紹了 CMoney 的 PAGEs 系統，以及團隊如何協作來為這樣的大型系統進行迭代，並解決規模化開發所帶來的挑戰。PAGEs 系統的核心優勢在於其可組合與可設定，使得 PM、工程師和設計師能夠簡單且高效地創建兩百個以上符合需求的元件，成功解決了傳統開發流程中的複用性問題，並實現了開發、測試、上架的自動化，加速產品的上市。

高效的開發流程不僅展示了 CMoney 團隊自我超越的精神，也強調了跨部門協作的重要性。對軟體工程師來說，能夠全面參與 App 開發過程是一個極佳的學習機會；對 PM 而言，PAGEs 系統則賦予了他們更多的彈性，能夠快速迭代產品，為用戶創造價值。

如果你也對工程技術、業界實際開發經驗分享有興趣，歡迎你參與下一次 CMoney 專業分享暨招募說明會，你將獲得與各部門主管零距離互動的機會！透過自由交流、專業 QA，讓你看見 CMoney 各職能的全貌，探索最適合你的職涯發展路徑。

也歡迎對 CMoney 技術團隊文化感興趣的夥伴加入我們，一同交流、共同成長！