Flutter無程式碼開發工具：Github Copilot、DhiWise、FlutterFlow

/ 程式設計

去年開始接觸Flutter，已經有成功發佈到TestFlight，近期有一個自己的需求想要寫，於是又入坑Flutter

這次有看到幾個比較特別的無程式碼開發工具，好好研究了一下，搞不好是神器

三個工具比較

GitHub Copilot

優點

  1. 代碼補全與自動生成：基於 OpenAI 的 Codex 模型，GitHub Copilot 能夠在多種編程語言中實時提供代碼補全和生成建議，適合提升開發效率。
  2. 支援多種編程語言：不僅限於特定框架，Copilot 支援 JavaScript、Python、Ruby、Java 等多種語言，適合多樣化的項目需求。
  3. 集成於 IDE 中：Copilot 可無縫集成在常用的 IDE（如 VS Code、JetBrains 系列），開發者可以在熟悉的環境中使用，提升開發體驗。
  4. 適合不同類型的任務：能夠處理範圍廣泛的任務，從簡單的代碼片段補全到複雜的算法建議，幫助開發者加快進度。

缺點

  1. 對上下文理解有限：Copilot 是基於模型的上下文預測，有時候可能無法準確理解複雜的業務邏輯，生成的代碼可能不符合需求。
  2. 生成代碼的準確性不保證：在一些高複雜度的場景下，Copilot 生成的代碼可能有錯誤或需要調整，開發者需要有一定的能力來檢查和調試。
  3. 安全和隱私問題：Copilot 有時可能會生成基於公共代碼庫的相似代碼，這可能會帶來潛在的隱私和版權問題。
  4. 缺乏完整的架構生成能力：Copilot 更適合代碼片段和函數級的建議，而不適用於從頭生成應用的結構或架構。

DhiWise

優點

  1. 代碼生成結構清晰且工程化：生成的代碼更符合開發標準和架構，便於維護，適合希望快速生成高品質代碼的團隊。
  2. 支援多框架：DhiWise 支援 Node.js、React、Flutter 等多種框架，適合多平台應用的開發需求。
  3. Figma 整合：提供 Figma 插件，可將設計直接導入並生成程式碼，簡化設計與開發的轉換流程。
  4. 自定義邏輯和 API 支援：DhiWise 支援自定義邏輯和後端 API 整合，使開發人員能夠構建複雜應用，特別是需要後端支援的應用。
  5. 模組化代碼結構：生成的代碼有良好的模組化結構，便於重用和擴展，適合長期維護的應用。

缺點

  1. 複雜應用的靈活性有限：DhiWise 生成的代碼在高複雜度場景下可能無法靈活應對，尤其是需要高度定制的應用。
  2. 樣式和邏輯的分離有限：某些情況下，樣式和邏輯可能被硬編碼，增加了全局樣式變更的難度。
  3. 第三方庫整合的限制：雖然 DhiWise 支援一些常用第三方庫，但對自定義插件或不常用庫的支援可能較少。
  4. 學習成本較高：由於 DhiWise 面向開發者，無程式背景的使用者可能會覺得學習成本較高，尤其是在需要定制代碼時。

FlutterFlow

優點

  1. 簡單易用的無程式碼平台：FlutterFlow 提供視覺化的設計工具，特別適合無程式背景的使用者上手，適用於快速構建 MVP 和跨平台應用。
  2. 支援即時預覽和測試：內建即時預覽功能，開發人員可以快速查看應用效果，便於原型設計和快速迭代。
  3. Firebase 整合：支援 Firebase 認證、資料庫等功能，使得後端連接更加便捷，適合開發簡單後端需求的應用。
  4. 自動生成 Flutter 代碼：生成的代碼可以下載並在 Flutter 中進行自定義修改，方便進一步開發。
  5. 跨平台支援：生成的 Flutter 應用可以直接部署到 iOS 和 Android 平台，適合需要多平台支持的專案。

缺點

  1. 代碼結構較臃腫：FlutterFlow 生成的代碼可能包含多餘的 widget 層級和硬編碼樣式，降低了代碼的可讀性和可維護性。
  2. 複雜邏輯支援有限：對於需要高度自定義的邏輯和狀態管理的應用，FlutterFlow 支援較為有限，需要手動進行補充。
  3. 高級開發工具不足：相比於手寫 Flutter 代碼，FlutterFlow 缺乏進階的除錯、測試工具，對於需要進行深入性能優化的應用來說不夠理想。
  4. 樣式重用困難：生成的樣式多為硬編碼，缺少靈活的樣式管理，若需全局變更樣式，維護難度較大。

結論：

  • GitHub Copilot：適合希望提升開發效率的工程師，尤其是在已有代碼基礎上進行補全和加速開發。
  • DhiWise：適合需要產生具備工程標準的代碼、並且需要後端支援的應用，適合工程化需求較高的項目。
  • FlutterFlow：適合快速原型設計或 MVP 開發，無程式背景的使用者或小型跨平台應用開發。
功能GitHub CopilotDhiWiseFlutterFlow
優點快速補全代碼、多語言支持、IDE 集成代碼結構清晰、多框架支持、模組化結構無程式碼、視覺化操作、Firebase 支持
缺點理解上下文有限、生成代碼準確性不保證複雜應用靈活性有限、樣式和邏輯分離不足代碼臃腫、複雜邏輯支援有限
適合的應用場景提高開發效率、快速生成代碼片段希望工程化代碼且需後端整合的應用原型設計、MVP 開發、簡單跨平台應用
代碼生成品質片段級代碼生成，依賴上下文工程化代碼，模組化結構，但靈活性受限可執行 Flutter 代碼，但結構臃腫
學習難易度適合熟悉程式語言的開發者需要一定的程式基礎，無程式背景的用戶可能需適應上手簡單，適合無程式背景的使用者

我自己個人的選擇

DhiWise根據官方介紹和影片，看起來生成出來的程式碼是蠻優質的，要能擴充出複雜需求，應該是沒問題，而且能先產出那些畫面和框架，剩下的只要根據框架去撰寫業務邏輯，這對於會寫程式只是不精Flutter的我非常友善

後續還要再做迭代新功能，要如何做

我繼續問ChatGPT他給我的答案是…

  1. 建立良好的代碼版本控制
    1. 使用 Git 或其他版本控制系統來管理代碼變更，特別是當初次從 DhiWise 生成代碼後。這樣可以追蹤每次變更，並且在出現錯誤時方便回滾到先前版本。
    2. 確保每次從 DhiWise 更新代碼或迭代新功能前，都創建新分支來進行開發，這樣可以避免直接在主分支上進行改動。
  2. 手動合併生成的代碼與現有代碼
    1. DhiWise 支援生成模組化和結構化的代碼，這樣您可以在現有專案中手動合併新增的代碼模組。由於新增的功能往往只是特定模組的變更，因此手動將生成的代碼合併進主分支，不會影響整個應用的基礎架構。
    2. 在每次增量更新時，確保只引入需要更新的代碼模組，例如某些新的 API 調用或視圖元件，而不會覆蓋整個應用的其他部分。
  3. 利用 DhiWise 的自定義代碼區塊
    1. DhiWise 支援在生成的代碼中嵌入自定義代碼區塊，這些區塊可以用來放置業務邏輯、狀態管理等特定功能。
    2. 自定義代碼區塊不會因後續 DhiWise 更新而被覆蓋，因此在後期的迭代中仍然可以保留，這有助於長期維護並避免覆寫原有邏輯。
  4. 使用 API 驅動的設計來擴展功能
    1. 將新功能設計成 API 驅動的模組，使前端代碼能夠隨著後端 API 的更新而自動獲得新的數據或邏輯支持。例如，新增的數據接口或新的數據模型可以通過 API 輕鬆整合到現有應用中。
    2. 這種方法能確保應用的邏輯和業務層分離，前端和後端的擴展互不干擾。
  5. 重複利用和擴展現有的組件和模組
    1. 使用模組化架構，將現有的代碼組件進行擴展或重用。例如，將原有的 widget 抽象為可重複使用的組件，這樣在新增功能時可以直接複用而無需重寫。
    2. 在 DhiWise 中將經常使用的元件和視圖抽象出來，以便在新功能中可以簡單地調用和擴展。
  6. 在 DhiWise 上逐步新增和測試新功能
    1. DhiWise 支援逐步地為應用添加新功能或模組。您可以先在 DhiWise 上構建新的功能模組，並在生成代碼之前進行測試，以確保其與現有應用兼容。
    2. 每次迭代前，先在 DhiWise 平台上模擬測試新的功能模組，確認功能模組無誤後再導出代碼進行合併，減少後期的錯誤修正。
  7. 進行代碼審查和測試
    1. 每次將 DhiWise 的代碼合併到應用中時，進行代碼審查，確保新的代碼不會對現有功能造成影響。
    2. 定期進行單元測試、整合測試和 UI 測試，以確保新功能不會影響應用的穩定性，並避免潛在的錯誤。
  8. 定期同步並更新 DhiWise 專案
    1. 當應用不斷迭代時，確保 DhiWise 專案和現有的代碼保持同步，並隨時將新的功能模組添加到 DhiWise 專案中。這樣可以保證將來的代碼生成能夠更符合現有應用的架構。

以上看起來是是可行的

待我驗證後再跟大家分享…