不用透過工程師，一週完成一支APP－ CMoney PAGEs－ low-code APP開發解決方案

CMoney為何需要做到APP大量快速開發？

你覺得，做一支股票看盤APP要多久？一季？半年？還是一年？……

如果我說只要一周呢？

___________________________________________________________________

CMoney的主力產品一直是股市相關的資訊軟體，從法人系統到PC端的應用程式，再到近年大量流行的手機APP，不乏許多知名的APP (諸如 籌碼K線、股市爆料同學會、艾蜜莉定存股、權證小哥全方位獨門監控 以及大大小小超過50支作者APP)

做了那麼多APP我們發現了幾個痛點：

1. 工程師會需要設定許多股市相關的參數，需要跟PM有很多來回溝通本

2. 工程師老是在重複做類似的功能，造成重工

3. 不同工程師做同一種功能有N種寫法，造成維護困難

4. 每次有重大BUG或功能要更新(例如更新登入模組)，每一支APP都要做一遍

因此我們會想要達到幾個效果

1. 因為有些參數資料設定的工不能省，所想讓PM代替工程師，降低溝通成本

2. 類似的功能我們想要重複使用，並讓PM自由的決定長相與參數

3. 修復或重大更新只需要做一次

而我們想到的解決方案就是：設計一套元件化的APP組裝系統，並用low-code/no-code的概念讓PM自行設定APP內的參數。

至於為什麼不是做一支超級APP包含所有功能而是要做哪麼多支APP呢？

簡單一句話就是：「投資沒有最好的方法，只有適合你的方法。」

所以我們會需要打造各種適合不同用戶的APP，做到體驗極大化。

延伸閱讀：吃力不討好的做了超過100支APP ? 為什麼不集中資源做一個APP就好? 談從使命延伸出的CMoney產品方法論。

low-code/no-code是什麼概念，為什麼我們會需要用它？

低代碼（Low-Code）和無代碼（No-Code）是兩種軟體開發的方法論，旨在降低開發應用程式的複雜度，使非開發人員也能參與應用程式的創建。以下是對這兩個概念的理解：

• 低代碼（Low-Code）：

定義： 低代碼開發是一種軟體開發方法，其中使用者可以透過視覺化的介面和少量的手寫程式碼，快速搭建應用程式。

特點：視覺化開發： 低代碼平台通常提供圖形化的拖放式介面，用戶可以透過拖放元件來設計應用程式。

• 少量手寫程式碼： 開發者仍然可以使用一些程式碼，但量通常較少，主要用於自訂特定功能或業務邏輯。
• 加速開發： 這種方法的目的是加速應用程式開發過程，降低技術門檻，使更多人能參與開發。

無代碼（No-Code）：

定義： 無代碼開發是一種更極端的方法，允許使用者創建應用程式而無需撰寫任何程式碼。

特點：

• 完全視覺化： 無代碼平台提供全視覺化的開發環境，用戶僅需透過拖放和配置，無需了解或寫任何程式碼。
• 極簡化： 這種方法的目的是極大地簡化開發流程，使非技術人員也能參與和理解。
• 快速原型： 無代碼平台通常適用於快速原型開發，尤其是對於一些簡單的業務應用。

總的來說，低代碼和無代碼的共同目標是提高應用程式開發的效率，使更多的人能夠參與和貢獻，從而滿足不同技術水平和背景的用戶需求。這兩種方法在當今快速發展的數位轉型環境中變得越來越受歡迎。

用一個更好理解的例子，就如目前大家常用來製作網頁的WordPress、WIX，就是一種low-code/no-code概念的網頁設計平台，用戶只要透過拖曳編輯文字選擇功能，就能夠快速地設計出自己的專屬的網頁，達到銷售、展示的目的。

PAGEs－一套 low-code開發的最佳解決方案

經過幾番討論，團隊提出了一個新的解決方案，並將它命名為PAGEs

PAGEs全名Portable Apps Gen & Edit system (可攜式APP建構與編輯系統)

他是一套透過GUITool來把元件組裝到BluePrint上然後生成APP的系統，PM或其他非工程職能，只要透過 low-code的GUITool，就能做到不動用工程師，一周產出一支APP！

接下來就讓我們一一拆解PAGEs怎麼運作

如果用蓋房子來比喻，Blueprint就是房子的設計藍圖，而繪圖工具就是GUI Tool，而元件就是蓋房子的材料，所以最終房子就會根據設計圖與工程師提供的材料(元件)興建完成

而要做到高效開發，有三個關鍵

1. Blueprint的繪製要足夠簡單

2. APP的建立流程要快速流暢

3. 元件的數量要夠豐富、變化性要夠多

GUI Tool－以low code方式組裝APP 降低工程成本

為了讓Blueprint的繪製足夠簡單，我們設計了一套圖像化界面工具(Graphical User Interface Tool，如下圖)，讓PM可以透過拖曳圖像的方式來組裝APP，並再透過設定參數與跳轉等功能(low-code的部分)，最終達到由非工程人員來實作APP的目的。

目前的複雜度在於有些程式碼轉GUI的過程，有些部分需要很細緻的規劃與網頁工程成本，因此在還沒完全優化之前，使用者可能還是要寫低度的程式碼。

BluePrint－建構APP的建築藍圖

目前的BluePrint會是以Json格式來記載整支APP會用的元件有哪些，包含他們要接哪些資料，元件的位置、高度等等，如此一來就可以建構出如藍圖設定的APP。

現況是在建APP時會把Blueprint壓到APP中，為了解決APP壓版的流程問題，後續會推進Blueprint上雲端的功能，就能夠達到更新Blueprint即更新APP，免透過商店的熱更新功能。

PAGEs 開發飛輪－關鍵是複用性高元件的數量

最後一個問題，如何讓元件的數量豐富、變化性高？ 答案很簡單，就是設計一套完整的開發流程，其中最重要的，就是每次實作元件如何提高其覆用性，並且考慮各種可能不斷壯大PAGEs元件群，以及優化系統架構。(如下圖)

有了上述的流程，如果所有APP都透過PAGEs建構，就能達到我們想要的更新一次全體APP受惠的效果，而且同樣的元件透過變化參數就能滿足不同的需求，加上有了GUI Tool降低來回的時間成本，撇除規劃與準備資料，目前實務上由PM組裝APP大約只需要1~2周的時間。(呼應第一段要解決的問題)

另外，幾個迷思還是要破除一下：

1. 因為要考慮到覆用性，用PAGEs開發就不能客製化了嗎？

答：這是錯誤的概念，即便是不能覆用的功能也能應該用PAGEs開發，原因是還是有大量的系統架構會重複使用，例如登入、購買、推播、埋點等等，這些如果有需要改動，不用統一的架構，就會有大量的維護成本。

2. PAGEs開發會不會反而變慢

答：短期會，但長期是變快，因為短期如果有較多不足的元件，確實會多花時間來建置，不過一旦累積足夠的覆用元件，就可以快速的滿足各種需求有一個先決條件是：你會有大量的覆用性元件會重複使用，只要元件量一累積起來，開發的速度就會飛快。

PAGEs開發的未來發展與隱憂

未來CMoney還是會持續推行PAGEs，並將其擴展到更多金融商品，並開始發展需要高度覆用性APP的市場(例如：學校、醫院、商家…)

短期內可能會花費較多時間製作元件，但長期而言，我們可能會覆蓋市面上所有可能的功能。

而目前CMoney仍致力與把各種常用的模塊都元件化，以達到需求滿足率最佳化，雖然發展元件是眼前目前看起來相對優的解決方案，但其實還是會有幾個風險－

1. 為了要使用Blueprint的開發邏輯，對於不熟悉的人還是會有額外的學習成本

2. 目前PM學習GUITool的成本還是較高，需要持續優化與製作教學

這些風險都是團隊需要一起克服與進化的，我相信都能一一克服。

投資不是只有錢，人生的每個決定背後都是一種投資

聽到投資大家想到的都是錢、股市等等，但我們認為在人生路上，你的每一個選擇造就了人生的結果，就如同投資股市一樣，你為什麼想買某一檔股票的背後都是經過分析後的決定，買了之後的後果也都由你承受，最有挑戰的是，投資股市並沒有所謂的標準答案，人生也是如此。

所以我們將我們的使命從解決大家財務投資的問題，延伸到人生重要的其他面向： 健康、工作、家庭與人際關係 ，形成了我們公司新的使命，擴大公司的服務邊界，我們也會把在財務領域的成功方法論拓展到這新領域，打造出真正能幫助用戶的產品。如果你對打造產品幫助別人的生活變得更好，歡迎你加入我們產品團隊 !