2021年初，釘釘帶火了低代碼，而在低代碼火爆的同時，隨之而來也帶來了行業亂象，這半年以來，小編看到很多公司，都自稱自己是低代碼，甚至隨便一個軟體公司都說自己是低代碼，這就讓人很費解了。 那麼，面對最近湧現大量低代碼玩家，我們該如何辨別低代碼平臺的「真假」呢？

下面把辨別方法詳細的告訴給大家。 按照這些維度打分，即可辨別喔~

而為了更好的研究低代碼，我們首先要探討，如何定義低代碼平臺？

一、如何定義低代碼平臺？

著名諮詢機構Gartner，於2020年9月發佈的《企業級低代碼開發平臺的關鍵能力報告》（Critical Capabilities for Enterprise Low-Code Application Platforms）中，定義了低代碼的11項關鍵能力。 也就是說，這11項關鍵能力是衡量一個平臺是否能夠稱之為低代碼平臺的關鍵因素。

先簡單瞭解一下各項要素的含義：

1、Intuitive， No-Code App Development：易用性，不寫代碼時的開發能力

在不寫代碼的情況下，能夠完成多複雜的系統搭建。 這是標識低代碼開發平台生產力的關鍵指標。

2、Application User Experience：所開發出來的應用的用戶體驗

它指的不是低代碼開發平臺本身的用戶體驗，而是通過低代碼平臺開發出來的應用，給到使用者的使用體驗。

3、Data Model and Management：數據模型和管理

這個指標就是通常所講的「模型驅動」 相比於表單驅動，模型驅動能夠提供滿足資料庫設計範式的數據模型設計和管理能力。 開發的應用複雜度越高，系統集成的要求越高，這個能力就越關鍵。

4、Process and Business Logic：工作流與業務處理邏輯

流程應用與業務邏輯開發能力和效率。 這個能力有兩方面：

第一，是指使用該低代碼開發平臺，是否可以開發出複雜的工作流和業務處理邏輯;

第二，是開發這些功能時的便利性和易用性程度有多高。

5、Platform Ecosystem：開發平臺的生態系統

低代碼開發平臺的本質是開發工具，當內置的開箱即用的功能無法覆蓋更多應用場景時，就需要基於該平臺的完整生態系統，來提供更深程度、更全面的開發賦能，比如開放的外掛程式機制。

6、API and Integration：程式設計介面與系統集成能力

為了避免「數據孤島」，低代碼開發平臺需要提供系統集成能力、程式設計介面，跟其它系統進行數據的互聯互通。

7、Architecture：系統架構

系統需要支援服務化、分層的架構方式，支援高可用、集群的應用部署方式。

8、Quality of Service：服務的品質

系統的健壯性、無故障使用時長、故障恢復時長，對CPU資源、硬碟資源佔用方式，對雲是否友好。

9、Persona and SDLC：使用者模型與軟體開發生命周期支援

軟體開發的生命週期中，包含設計、開發、反饋、測試、運維等多個環節，低代碼平臺要支援單元/集成測試、聯調、發佈、回滾、持續反覆運算等。

10、Governance：治理及運維

現代軟體開發中的敏捷開發、代碼庫管理，版本許可權，發佈管理等，在低代碼平臺中，都要能夠支援。

11、Security and Compliance：安全與合規

低代碼開發平臺需要提供：靈活的部署方式、安全機制和許可權控制、SSL數據傳輸、密碼強度策略、跨域訪問控制、高粒度的用戶許可權控制等等。

以上就是Gartner對低代碼平臺定義的11個要素，相信許多技術人員已經對低代碼有個大致認識了。 但是，想要識別和判定一個低代碼平台的話，直接使用以上11個要素，就有點太繁瑣了。

二、如何辨別低代碼平臺的「真假」？

我結合軟體工程全生命周期實踐，以及Gartner定義的11個要素，給「低代碼」平台擬定了6個維度的判定標準：

1、拖拽式開發;

2、對象封裝與數據模型;

3、模型驅動;

4、腳本語言;

5、軟體測試與部署;

6、API與集成。

1、拖拽式開發

拖拖拽拽做開發，就是"低代碼"開發平臺給大家最直觀的印象，所以也是"低代碼"開發平臺最基本的特徵。

這一點，世面上的許多"低代碼"平臺都能夠做得到，可以說是個送分題，如果你家的軟體產品連這點都做不到，就不要吃"低代碼"這碗飯了。

2、對象封裝與數據模型

這部分指的是低代碼平臺要操作的對象、數據模型、表達式等等，它可以是高度抽象和封裝的物件，可以省略掉"類"、"介面"、"函數"這些程式設計語言的高級特性，以更簡化的方式提供出來，供程式調用。

3、模型驅動

"模型驅動"是相對於"表單驅動"的，指的是對於數據進行建模和處理，比如國外的低代碼平臺OutSystems、Mendix，就有很強大的模型驅動的能力，包括了定義實體、實體關聯、主鍵、索引、數據查詢等等。

4、腳本語言

腳本語言實際上就是程式設計語言了，是低代碼平臺實現複雜業務邏輯的擴展，可以使用 JavaScripts、Python、Java等語言進行程式設計。

但是，低代碼平臺會把語言的編譯過程做好封裝，做到一鍵發佈，即時運行，方便代碼調試。

5、軟體測試與部署

低代碼開發平臺，本質上是軟體開發工具。 所以整體開發過程也要遵守軟體工程的流程規範。 只是把許多環節都做了簡化、內部封裝，降低了學習成本、開發成本、測試成本、部署成本。

6、API與集成

主要是解決低代碼平台開發出來的系統，跟其它外部系統的數據互聯互通，否則又是造了一堆大煙囪，一些數據孤島。

以上6個判定標準怎麼使用呢？

每個維度1~10分，總分36分是及格線。 分數越高，表示這個低代碼開發平臺越完善、成熟度越高。 通過這個方法，可以簡單判斷一個低代碼平臺，是真低代碼，還是偽低代碼。

結語：

合理並且有效地運用低代碼平臺，不僅可以讓我們工作高效地運行，還能最大程度保證團隊目標的達成。 我推薦使用織信Informat，它內置100+標準應用範本，覆蓋：OA協同辦公、CRM客戶管理、ERP進銷存、MES生產管理、流程審批、人事績效、企業服務、個人及組織等多個應用場景。 點擊一鍵安裝，即可免費試用。 並且擁有在線搭建功能，可根據企業需求實現自主配置。 是幫助企業開啟數位轉型的重要引擎。 現在註冊還可享終身免費使用權益。

近兩年，低代碼開發在國內市場獲得了前所未有的熱度，很多投資機構都做了相關的分析與預測。 根據知名國際諮詢公司Gartner預測：到2025年，將會有70%的新應用由低代碼/無代碼技術完成開發。 那麼，低代碼真的是新風口嗎？ 它真的可以提升開發效率嗎？

帶著這些疑問，小編決定深入體驗下，幫大家一探究竟。

一、低代碼優劣勢一覽

低代碼優勢：

低代碼開發方便、簡單、易用，支援拖拽設計模式，如果沒有過多的複雜功能要求，通過範本5分鐘就可以建立一套應用程式，並自動適配UI頁面。 同時，使用者無需關心數據存儲、運營環境、伺服器配置和網路安全等問題，只需要理清自己的需求進行應用創建即可。

低代碼的劣勢：

低代碼目前還無法匯出應用原始程式碼部署在其他平臺上，只能依附在web、企業微信、釘釘工作臺上使用。 想實現更高級的功能，例如，動作的創建，頁面提交判斷需要有一定的程式設計邏輯才能完成。 如果是大型集團用低代碼開發應用程式，則需要有專業的IT人員配合才能開發出更高效、符合業務標準的功能。

總體來說，只要使用者邏輯清晰，並能熟練使用Office、OA、ERP等其中一種軟體工具，那麼都能通過低/無代碼拖拽方式開發出自己想要的應用程式。 尤其是對於那些預算、人手不足的企業來說，通過低/無代碼開發應用程式將節省一大筆支出。

二、低代碼如何搭建應用？

下面，以織信低代碼為例，給大家講解一下如何快速搭建應用。

目前該低代碼平臺創建應用的方式有2種，一種是導入已有的應用範本，另外一種是創建空白的新應用。

1、從應用商店下載範本使用：

如果我們選擇安裝已有的應用範本，則能快速體驗織信低代碼平臺的實現邏輯，這也相當於節省了前期搭建的準備工作，直接步入使用階段。

選擇這種模式，我們可以根據自身的需求來選擇對應的應用範本。 比如：OA系統、生產設備管理、人事行政管理、IT專案管理、採購管理、進銷存管理等等。 大概有100多個範本，基本涵蓋了大部分企業所需要辦公場景。

假設，此時我們已經從範本中安裝了一個OA系統，進入應用后，左邊是模組清單，比較常規的功能有：人事管理、資產管理、費控管理、流程審批、部門總結等內容。

右側是儀錶盤（報表統計），通過已有數據一鍵生成儀錶盤視圖，企業目前有多少人、入職年限、學歷分佈、性別佔比、職務分佈、平均年齡、婚姻狀況、員工星座分佈等內容一覽無遺，方便企業開展活動、也利於管理層快速決策。

當然了，右側區域我們除了可以設置儀錶盤展示外，還可以自定義設置數據表內容、知識庫、檔存儲、外部系統、網站等內容。

我們還可以通過創建「數據表」對企業進行訊息化管理，數據表內支持數據的批量錄入，我們只需使用一鍵導入功能即可實現。 （該功能支援Excel檔、網頁內容、文本、api位址的批量導入。 ）

如需要新增新員工的個人訊息，我們可以在新員工入職的時候，生成一份調查問卷，把需要填寫的內容設置為顯示，一鍵生成調查問卷，新員工只需通過連結或掃碼的方式，就可完成對訊息的錄入。 而所錄入的訊息，均會同步到OA系統-員工管理數據模組中。

除了這些功能以外，在OA辦公系統中，我們最常用的就是"請假"功能，這裡也順便給大家演示一下如何用低代碼平臺搭建"流程審批"。

第一步：在OA系統左側，找到"流轉審批"模組，點擊··· （3個點）進入模組"設置"。

第二步：進入設置，找到最右側的"審批"點擊進入;點擊"創建審批流程";添加名稱、成員、部門並保存;然後再新建流程圖。

第三步：完善審批流程圖並保存，最後「啟用」審批流程即可。

"審批"支援串聯審批及並行審批，操作上支持轉交、回退、駁回，基本涵蓋所有審批工作。

使用感受：

通過織信應用商店下載範本的方式，使用低代碼構建OA系統，能讓系統變得更具靈活性。 而且，通過該方式構建OA系統它與傳統框架的OA系統有所不同。

低代碼的OA系統除了可以讓我們通過自主配置的方式，快速實現員工、部門、績效、考勤、資產、費控、審批管理等內容，還可以利用模組化設計進行現有功能的調整或者自定義功能的搭建。

不僅如此，低代碼系統還支援穿插各類模組的數據進行可視化匯總。 在搭配自定義審批鏈和自動化之後，可以實現對任意數據的預警提醒併發送到相應的責任人，有助於全面提升員工自我管理與企業整體管理的效率。

2、新建空白應用（從零搭建）

跟第一種下載範本搭建應用的方式不同，這第二種「新建空白應用」方式，裡面什麼內容都沒有，面對這種情況，我們該如何搭建呢？

下面，我們依舊以織信低代碼平臺為範例進行講解！

比方說，我們需要在短時間內搭建一款進銷存系統，給某生產加工企業使用。 首先我們該怎麼做呢？

第一步：明確業務場景

首先我們要明白，如果是搭建一個進銷存管理系統，這其中就要涉及到多種原料的進料、用料、庫存統計、供應商管理及員工的領用記錄，如果我們希望通過這款進銷存系統對相關訊息進行高效管理，減少不必要的數據錄入工作，那麼使用這套系統的相關人員有：倉庫管理員、質檢員、加工組。

第二步：梳理工作流程

第三步：構建系統架構圖

要搭建一個進銷存系統，整個系統流程要形成閉環則需要5張表，建立一個"屬性"字段來區分【成品】和【原料】

準備工作完成，下面正式進入搭建應用環節。

第四步：創建應用

首先，我們登錄後台，點擊創建新應用，然後填寫應用名稱，選好應用顏色，再找個相應的圖示，添加分組，最後點擊"創建"。

第五步：創建表單

創建並進入應用後，首先我們要按照系統架構圖中，創建好"入庫清單、出庫清單、庫存表、質檢表、生產中控"5張空表。

第六步：創建欄位

選擇表頭右側的小箭頭，點擊【設置】，進入表單設置。

找到【表單欄位】，這裡可以進行欄位的增減修改，按照系統架構圖，將各表的欄位都建立出來。

欄位類型根據所填數據類型的不同多種可選，例如「屬性」就應當使用單選，數量就用整數，普通文本選擇單行文本。

第七步：設置關聯關係

如圖一所示，建立對應欄位，【原料名稱】的欄位類型要採用【關聯記錄】，關聯到庫存表（字段類型涉及"關聯"的一律採用新建，不要在已有欄位上直接修改）

建立完成後回到表頭，點擊圖三按鈕彈出【表格設置】，下拉到底，選擇【顯示所有】即可看到剛才所新建的字段（此舉是為了防止多人協同辦公時有人新建字段導致數據錯亂）

關聯關係介紹

● 關聯記錄就好比是一座橋，起到連接兩表的作用，一切關聯的後續功能都是建立在有【關聯記錄】的基礎上;

● 有了關聯記錄，才可以使用【關聯記錄查詢清單】實現兩表互相的自定義字段查詢。

● 而有了【關聯記錄查詢清單】，才可使用【關聯清單匯總】，實現某一類數據的匯總求和或其他函數計算。

● 【關聯記錄欄位】只需有【關聯記錄】即可，實現查找到某條記錄的某個字段數據的功能。

第八步：完成各表設置

參照步驟四，分別將剩餘表頭的欄位建立完成，再把關聯關係設置完成即可。

到此，一個進銷存系統已基本搭建完成，下面我們再根據流程測試一下。

雖然前面只建立了五張表，但實際在操作中只需使用3張表即可。

● 倉庫管理員-【庫存表】

● 加工組-【生產中控】

● 質檢員-【質檢表】

之所以這樣安排，也是為了避免數據的重複填寫。

入庫

入庫涉及的角色有兩類，倉庫管理員及質檢員，所以需要填寫的表只有兩張。

倉庫管理員直接在【庫存表】中點擊創建;

在入庫記錄中填寫相關入庫訊息。

質檢員在【質檢表】內點擊創建;

以入庫批次號作為質檢記錄的跟蹤依據;

入庫-2

如下圖【庫存表】中新增了3條庫存訊息，【入庫清單】實現自動帶入更新。

用料-1

同理【生產中控】中新增一件產品，生產本產品需要三樣原料，【用料清單】實現自動帶入更新，同時【庫存表】也自動更新庫存量，實現閉環。

用料-2

【庫存表】自動更新庫存;

【質檢表】可關聯相應生產批次的訊息。

完成這些，你覺得流程已經跑通了嗎？ 其實，還差最後一步...

作為一款業務系統，怎麼能少得了「許可權管理、審批流程、數據儀錶盤、範本列印」等功能呢！

許可權管理

點擊應用頂部，進入應用設置;【角色許可權】-創建新的使用角色，給每個角色配置相應的可視/編輯許可權;

審批流程

【審批】支援串聯審批及並行審批，操作上支持轉交、回退、駁回，基本涵蓋所有審批工作。

數據儀錶盤

【儀錶盤】提供數據報表分析

列印範本

針對每張表可獨立設置列印範本，適用於各種列印場景，如：工牌列印、報銷列印、發票列印、證書列印等等，還支援批量列印，堪稱企業日常辦公神器~

除此之外，織信低代碼平臺為了説明新手快速創建應用程式，推出了一系列的新手視頻教程，包括：説明中心、上手視頻等板塊。 基本所有在創建過程中遇到的難題，説明中心和視頻教程都有詳細的解答。 尤其是有程式設計基礎的使用者，可以通過説明中心實現更強大的功能。

最後，通過無代碼可視化拖拽操作方式創作的應用程式，讓人有一種發自內心的成就感。 低代碼/無代碼的出現使得程序開發不再是少數人的專屬，任何有想法的人都可以快速創建自己的應用程式。

同時對於專業的開發人員來說，低代碼開發方式可以將底層繁瑣、重複的程式封裝起來，從而實現更高的開發模式。 所以，無論你是學生、白領還是沒有任何程式設計經驗的業務人員，都可以嘗試下低代碼/無代碼開發，這對於以後的職場發展將起到重要的説明作用。

三、結語：

來自Gartner的數據顯示，要滿足台灣企業的所有數位轉型場景，需要開發至少5億個新的應用系統或者App。 這個龐大的需求，如果按傳統的產品研發模式，不僅成本高昂，產品的輸出和供給也受到限制。 低代碼平台的出現，不但能解決這個難題，還能發揮低代碼配置靈活和複用性高的特點，為企業提供更加精品和優質的應用服務。

合理並且有效地運用低代碼，不僅可以讓我們工作高效地運行，還能最大程度保證團隊目標的達成。 我推薦使用織信Informat，它內置100+標準應用範本，覆蓋：OA協同辦公、ERP進銷存、CRM客戶管理、人事績效財務、企業服務、個人及組織等多個應用場景。

隨著互聯網不斷發展，數位轉型早已成為企業發展的新動能。 作為企業數位轉型的重要工具、連接日常生活與全球經濟的新命脈，軟體顯得尤為重要。 然而，傳統軟體開發需要代碼，時間長、成本高、反覆運算慢——是企業無法避開的痛點。

如今，備受矚目的低代碼開發平臺便成了企業化解數位轉型難題的利器。 它專注於提升業務效率，直擊技術產品開發反覆運算速度嚴重滯後於企業業務高速發展等痛點，讓企業的內部管理和對外業務快速實現在線化、數據化，幫助企業降低軟體開發成本、技術和人員門檻。

低代碼開發

低代碼開發本質上是一種類似於搭積木理念、主要應用於企業訊息化領域的快速開發技術。 普通人員和專業開發者藉助功能強大的可視化開發方法，通過一個直觀的圖形使用者介面，以拖放式元件和模型邏輯，即可在網路和行動裝置上將應用程式開發的速度提升10倍以上。

以某低代碼開發平臺為例，在開發應用程式的頁面上，通過拖拽功能元件快速搭建應用程式，無需手動輸入代碼。 舉例來說，從前需要兩周才能開發的表單流程類應用，如今普通業務人員只需2小時就可完成，大大縮短了定製開發的時間、提升了業務的效率。

發展現狀

01 低代碼開發市場需求暴增

從2018年後半年起，隨著雲計算的興起及移動互聯網的高速發展，企業上雲的拐點到來——雲計算改變了企業訊息化基礎架構，移動互聯網發展帶來大量數據通道，企業的訊息化需求變多、變新。 低代碼開發以其高效、靈活、穩定等特性，快速地得到了市場的認可和接受，迎來行業爆髮式增長。 以往那些較注重訊息安全的行業，如政府、銀行、採礦業、醫療保健、保險，甚至是國家安全機構等，因其超級自動化和可組合業務的興起而亟需互聯網技術工具，紛紛選擇低代碼開發平臺。

根據公開資料，2013年至2020年，低代碼開發平台的業務收入一直保持著兩位數的增長速度。 2020年，臺灣低代碼行業市場規模達到了15.9億，同比增長80.2%。

02 低代碼開發市場競爭激烈

低代碼開發平臺在國內經過近二十年的發展，已經非常成熟，市場日漸火熱。 國外成熟的低代碼開發平臺，例如Outsystems、Mendix等廠商，其重要的商業化收入，就是為中大型客戶提供企業內部應用開發的私有化部署。 而國內外的互聯網巨頭，如：谷歌、微軟、阿里、騰訊、華為等，也先後佈局低代碼開發平臺，甚至連初創企業也不斷加入戰局，推動市場迎來新一輪爆發期。 不過，激烈的市場競爭，也為企業帶來了更多的選擇。

發展趨勢

01 未來的市場規模

據全球最具權威的IT研究與顧問諮詢公司Gartner的最新預測，2021年市場對於應用開發的需求將5倍於IT公司的產能。 為了填補產量缺口，低代碼技術作為目前唯一可行的解決方案，必然吸引越來越多企業引入。 預計2021年，全球低代碼開發平台市場將達到138億美元，比2020年增長22.6%。

全球知名研究與諮詢機構Forrester，發佈報告稱：預計在2021年，75%的應用程式將在低代碼平台中開發。

隨著低代碼開發技術的進步與行業經驗的積累，未來越來越多的應用場景將被挖掘，行業仍將維持50%以上的復合增長。

02 數字業務加速應用交付

在數位化時代，訊息和數據能力成為企業應對市場的核心能力。 數位業務的不斷加速，要求應用程式的交付、價值實現的速度變快。 支持數位轉型的定製軟體解決方案的增長，促使低代碼開發市場不斷壯大。

03 應尤其注重打通數據孤島壁壘

隨著各類企業系統的普及，不同版本的訊息化管理系統，令企業內部的數據難以共通，導致數據孤島現象的產生。 相對大型行業軟體和各類互聯網工具而言，企業要求低代碼開發具有更高的集成性——具備與其他系統，特別是核心業務系統的集成能力，讓各系統的數據流動起來，指導業務工作，提升運營效率。

04 繼續提升易用性及靈活性

隨著引擎種類和交付模組數量的增加，低代碼開發平臺應更加關注平臺的完整度和自定義能力——從數據、分析到系統，每個環節都需滿足客戶的個人化需求，還需注重操作簡便化。

05 佈局產業生態鏈以提升競爭力

通用型廠商由於應用場景更廣泛，拓客範圍大、速度快，目前廠商的數量更多，競爭更劇烈。 而垂直型廠商則在細分領域更有優勢——繼續深入挖掘，可發現更多的應用場景。 相對而言，佈局低代碼產業生態鏈、多維度拓展的廠商，在競爭中更有優勢。

06 低代碼平台+RPA+AI，加速企業數位轉型

低代碼平臺、RPA和AI各具特色，逐漸融合將成為趨勢。 "低代碼平臺+RPA"，利用RPA自動化工具，減少人為操作，使開發工作更便捷、快速。 "低代碼平臺+RPA+AI"的組合則更為智慧，是企業和個人提高效率、提升價值的工具，將其應用在業務場景中，可促使企業運營更為自動化、智慧化，促進企業數位轉型。

低代碼開發平臺把企業數位化需求和互聯網技術資源連接起來，讓企業可以「快速開發、靈活實施」，及時響應業務。 針對致力於實現數位轉型和運營創新的企業而言，低代碼開發平臺是非常值得邁出的一步。

從當前開發領域的發展趨勢來看，低代碼開發是一個重要的發展趨勢。 在未來的平臺化開發時代，低代碼將得到大面積的普及，這種開發方式不僅會提升軟體產品的穩定性，同時也會降低開發人員的工作壓力，使程式師開發更加高效。

那麼今天我們就來說說，MyApps低代碼開發平臺是如何使程式師開發更加高效！

（1）技術架構領先，多數據源整合

MyApps平臺採用業內領先的SpringBoot微服務架構、支援SpringCloud模式，完善了平臺的擴增基礎，滿足了系統快速開發、靈活拓展、無縫集成和高性能應用等綜合能力;支援MSQL SQL、SERVER、DB2、ORACLE等主流資料庫。 支援介面類型多、整合功能多，省去臨時開發介面和繁瑣溝通和技術工作量，使程式師開發更加高效。

（2）開發速度加快，所見就是所得

傳統開發是通過程式師每天碼上千或上萬的代碼進行開發系統，甚至會出現重複的情況。 這使得開發的人員的工作枯燥且壓力大，如果不小心寫錯一個代碼就會全盤複查，浪費時間也浪費精力。 MyApps平臺提供全可視化的開發環境、豐富的開發元件及多種案例範本，降低了應用軟體的開發難度，使用者無需從零開始，使程式師節省80%以上開發工作量。

（3）進化能力強大，滿足使用者需求

MyApps平臺擁有穩健、易拓展的設計架構和豐富的開發介面，同時支援版本管理，使得平臺具備優秀的自我進化能力，程式師通過平臺配置的應用可直接在web頁面進行維護和修改，並根據自身不斷變化的業務需求靈活的配置相關功能，方便快捷，高效開發！

對於程式師而言，低代碼開發平臺是一款能夠提高開發效率的不可或缺的工具，優秀的低代碼開發會在一定程度上促進專業程式師的崗位升級，使更多的專業程式師向研發級崗位發展，從而把更多的精力投放在產品創新上。 MyApps低代碼開發平台有著十餘年以上的專案成功經驗，除此之外還提供社區論壇供廣大開發者共同使用，產品的優勢決定了MyApps平臺成為程式師的不二選擇。

天翎3w+技術論壇會員，等你來加入~

剛剛上手一個低代碼開發平臺，測試評估以後您可能會選擇一款您相對比較滿意的或者已經征服您的低代碼開發平臺，此時你可能已經迫不及待的希望實踐一個專案了。 但是第一次使用低代碼您或多或少心裏還是有所芥蒂的。 如何選自一個項目開始使用低代碼開發專案？ 這裡我的一些建議：

1） 因為是初次嘗試，新產品的學習成本，磨合成本等等可能都會讓你覺得專案的專案的成本似乎不降反升，這些都是正常的，第一個專案，我們的對自己的要求就是第一個專案不要想著掙錢，要有只要不賠錢就行的心裡預期，掙錢的機會在後面;

2） 最好將第一個專案定義成試水專案，盡量使用低代碼產品多開發一些功能，盡量將多測試一些場景，而且盡量找一些通用的場景進行測試;

3） 盡量找熟人的專案，既然是要嘗試，那麼風險可能是不好控制的，如果專案的甲方是熟人，風險又能降低一些（如果您有豐富的行業經驗，可忽略此項）

4） 如果第一個專案完美交付，之後就可使用低代碼走該行業的路線，因為需求大同小異，很多時候，都會是在復用第一的專案，第一套沒掙的錢，都會在第2，3,...... 套掙回來，而且低代碼的優勢也能發揮的更好

最近低代碼概念開始炒起來了，如果大家留意，最近各種開發者大會和技術大會，都會有低代碼的專題。

與使用計算機程式設計語言構建應用程式的傳統方法不同，低代碼開發平臺是使用圖形精靈來創建和構建軟體的應用程式開發平臺。 因此，在許多情況下，低代碼或無代碼（幾乎沒有代碼）這個名稱是作為可視化開發工具來幫助設計人員進行拖放、元件瀏覽器和邏輯構建器的。

低代碼/無代碼的主要概念並不新鮮，它可以追溯到十多年前的無代碼程式設計 （PWCT） 和類似系統。 但是，這一概念在開發者社區中並沒有那麼可用或得到支援。 如今，數十種低代碼/無代碼平臺和服務湧入互聯網;因為事實證明，這一概念不僅僅適用於快速專案的原型設計。

外媒 Medevel 整理介紹了供個人和企業使用的最佳開源低代碼和無代碼平台清單。 具體如下：

1、Saltcorn

Saltcorn 是一個無代碼資料庫管理員 Web 應用程式。 它配備了一個引人注目的儀錶板、豐富的生態系統和視圖構建器以及可主題化的介面。 幾乎沒有編碼經驗的使用者可以在幾分鐘內構建一個豐富的互動式資料庫應用程式。 公司也可以使用它來創建日常使用的工具並即時重新塑造它們。

Saltcorn 有一個令人印象深刻的範例應用程式清單，其中包括：部落格、位址簿、專案管理系統、問題跟蹤器、wiki、團隊管理等。 Saltcorn 採用 MIT 許可作為免費開源項目發佈。

• https://github.com/saltcorn/saltcorn

2、捷得Joget DX

捷得Joget DX 是一個低代碼應用程式構建平台，可簡化公司的數位轉型。 它將業務流程自動化管理、工作流定製與低代碼應用程式開發工具相結合。

捷得Joget DX 可以在雲端和本地運行。 它有豐富的文檔、易於使用的儀錶板和可視化構建器，支援拖放和獨立於操作系統和資料庫。

• https://www. joget.cn/

3、Digdag

Digdag 是一款開源企業解決方案，旨在實現易於部署、多雲設置和模組化的結構來構建和擴展業務應用。 Digdag 擁有一系列企業功能，包括豐富的管理面板、多語言支援、錯誤處理、配置工具和版本控制工具。 該解決方案採用Java和Node.js開發，支援 AWS、私有雲、IBM 雲和 Digital Ocean。

• https://www. digdag.io/

4、Stackstorm

Stackstorm 與此列表中的任何其他系統不同，它被設計為在一個平臺內連接、管理和監控企業應用程式的 umbrella。

Stackstorm 專注於事件驅動方法、自定義工作流設計以及使用者角色和許可權。

方法很簡單：事件驅動的自動化，通過豐富的日誌記錄系統提供感測器、觸發器、每個定義的操作、規則、工作流和審計。

• https://stackstorm.com/

5、CUBA Platform

CUBA 平臺是一個面向企業的開源（Apache 2.0）快速應用開發系統。 它帶有數十種工具作為 IDE、應用程式構建工作室、CLI 命令行介面和可靠的可擴展基礎設施。 CUBA 平臺有一個豐富的外掛程式系統，其中包含一個 BPM（業務流程管理）附加元件，需要花費一些時間來構建和安裝。

• https://github.com/cuba-platform/bpm
• https://github.com/cuba-platform/cuba

6、Skyve

Skyve 是一個開源的業務軟體構建平臺。 它支援無代碼和低代碼的快速應用開發。 支援不同的資料庫引擎：MySQL、SQL 伺服器和 H2 資料庫引擎。 其開發人員目前正在努力支援PostgreSQL和Oracle。 Skyve提供了豐富的 API 集，以及低代碼開發應用構建精靈。

Skyve 平臺由豐富的生態系統組成，其中包括：

• 企業平臺，
• 構建器應用程式，採用React Native構建原生移動應用，
• 與其他第三方服務集成的Skyve總線模組，
• Skyve Confidence：為TDD提供測試功能
• Skyve Cortex：
• Skyve Portal：企業應用的 Web 門戶擴展
• Skyve CRM：自定義構建Skyve CRM 應用程式
• Skyve Replica：在分散式 Skyve 實例之間提供無縫同步
• https://github.com/skyvers/skyve

7、Rintagi

Rentagi 是一個專注於行動的低代碼企業級應用程式構建平臺。 它也是完全免費和開源的解決方案，這使其成為中小型公司的完美解決方案。 配備了豐富的複雜工具，可用於快速構建應用程式以提高生產力，它還為移動開發人員提供了豐富的開發人員友好的 API。

• https://medevel.com/rintagi/
• https://github.com/Rintagi/Low-Code-Development-Platform

8、Opexava

OpenXava 是一個低代碼應用程式構建平臺，主要關注生產力、簡單性和可用性。 作為一個使用 Java 技術構建的跨平台系統，它運行在 Linux 和 Windows 伺服器上。 它可能看起來像一個遺留系統（stated 2005），但它仍然是許多企業的首選。

OpenXava 確保了高生產力、較短的功能學習曲線、大量的企業功能以及完整的移動和平板電腦回應式佈局。 OpenXava 是一個免費的開源社區版，但企業可以購買不同的額外功能版本。

• https://www. openxava.org/en/ate/low-code-development-platform

9、Convertigo

Convertigo 是無代碼和低代碼平臺的混合體。 它旨在説明公民開發人員和認真的開發人員在短時間內創建企業級應用程式和工具。 為開發人員提供本地安裝、雲版本和 MBaaS 版本。 它具有行動構建器工具、視覺化拖放UI、低代碼後端、REST/XML 轉換器、REST/JSON 轉換器、管理控制台等。

Convertigo 提供完整的 PWA（漸進式 Web 應用程式）、iOS 和 Android 移動開發支援。

• https://www. convertigo.com/

10、Tymly

Tymly 是一個業務優先的低代碼平臺，用於創建可擴展的伺服器應用程式。 它是在 MIT 許可下作為開源項目發佈的。

Tymly 引入了藍圖概念，將業務流程、功能和工作流封裝到藍圖中。 它有一個生態系統和藍圖存儲，可以保護大量的開發資源。 藍圖保存在 JSON 模式中，而數據保存在 PostgreSQL 資料庫中。 開發人員可以通過在 JSON 模式中定義他們的需求、業務功能和工作流來編寫他們的藍圖。

• https://medevel.com/tymly-low-code/
• https://github.com/wmfs/tymly/

11、JUDO

JUDO.codes 是另一個面向企業使用的低代碼平臺。 在數據建模、UI 設計和開發方面，JUDO 為開發人員提供了比此清單中其他低代碼平臺更大的靈活性。

JUDO 可用於 Windows、macOS 和 Linux 的可安裝包和二進位應用程式包。 （* macOS 安裝程式即將推出）。

JUDO.code 門戶為新手提供了豐富的文檔和一套教程。 它還提供了廣泛的使用者指南以及應用程式平臺的安裝說明。

• https://www. judo.codes/

12、OpenCatapult

OpenCatapult 是一個開源的低代碼DevOps自動化平臺。 它通過動態管理自動化的例行任務，説明DevOps和伺服器管理員更好地控制他們的伺服器。

不過，OpenCatapult 僅適用於 Windows x64 平臺，但開發人員正在計劃在不久的將來發佈 Linux 和 macOS 版本。

• https://github.com/Polyrific-Inc/OpenCatapult/

13、BudiBase

BudiBase 不僅僅是另一個低代碼平臺，它與這裡的其他平台有著不同的目標，因為它專注於為開發人員提供工具，以加快一個平臺內的開發、部署和集成過程。

• https://github.com/Budibase/budibase

14、Generative Objects（GO）Platform

Go Platform 是一家法國公司，致力於企業低代碼開發平臺。 側重於更好地控制應用程式生命週期、開發人員之間的協作，以及與其他平臺、桌面、移動和 Web 開發的軟體整合。

Go Platform 採用基於模型的應用程式開發方法，在專注於解決方案而非工具時節省時間、金錢和精力。

• https://www. generativeobjects.com/

15、Baserow

Baserow 是一種用於動態創建、管理資料庫和構建資料庫應用程式的迷人工具。 它具有確保高生產力和可用性的功能。

因為Baserow是一個模組化系統，它提供了一個完整的REST-API無頭系統，所以它吸引了行動開發人員的注意，將其用作他們應用程式的後端。 Baserow 正在積極開發中。

• https://gitlab.com/bramw/baserow

16、OS.bee

OS.bee 是一個免費的企業開源平臺，它將低代碼和無代碼與模型驅動的應用程式開發策略相結合。 該平臺由一家專業打造企業ERP系統30多年的公司打造。

OS.bee 提供了用於創建應用程式數據模型的可視化模型和圖表構建器。 該系統是用 Java 建立的，並提供 Eclipse 安裝和整合。

• https://www. osbee.org/home/

17、nuBuilder

nuBuilder 是一個免費的開源 RAD（快速應用程式開發），用於在幾分鐘內構建企業資料庫應用程式。 它是自託管的、低代碼的，具有高度可定製的後端系統。 它使用 PHP、HTML 和 JavaScript 和 MySQL 資料庫。

• https://www. nubuilder.com/

18、Metabase

Metabase 是一個開源的面向數據的可定製儀錶板，支援廣泛的資料庫後端，如 MongoDB、MySQL、PostgreSQL、SQL Server、Oracle 等。 它提供了一個用於管理資料庫記錄、操作數據、操作記錄的可視化方法、支援連接、多重聚合、高級過濾和全文搜索的層。 它是在幾分鐘內為企業創建具有高生產力和可用性的高效資料庫就緒儀錶板的終極解決方案。 Metabase 包含令人驚歎的視覺小部件，其中包括：圖表、地圖、SVG 向量地圖、分析以及為使用者、開發人員和 DevOps 提供的豐富的詳細文檔。

低代碼/無代碼開發平臺使用圖形精靈構建軟體，而不是像傳統方法那樣使用計算機程式設計語言來構建應用程式。 在本文中，我們介紹面向個人和企業使用者的18個開源的最佳低代碼/無代碼平臺。

低代碼/無代碼指的是提供可視化開發工具，支援拖放，內置元件瀏覽器和邏輯構建器。 低代碼/無代碼的概念並不新鮮，這可以追溯到十多年前的無代碼程式設計技術 （PWCT） 以及類似的系統。 然而，這一概念在開發人員社區中並未得到支援。

如今，數十個低代碼 / 平台和服務正蜂擁而至，因為事實證明，這個概念不僅僅是可用於快速原型專案。

1、Saltcorn

Saltcorn是一個無代碼資料庫管理Web應用。 它配備了一個吸睛的儀錶板，豐富的生態系統、視圖生成器以及支援主題的介面。

沒有什麼編碼體驗的使用者可以在幾分鐘內構建豐富且互動式的資料庫應用程式。 公司還可以使用它來創建日常使用的工具，並快速重構。

Saltcorn 擁有令人印象深刻的範例應用程式清單，其中包括：部落格、通訊簿、專案管理系統、問題跟蹤器、wiki、團隊管理等。

Saltcorn採用MIT許可作為免費開源項目發佈。 你可以點擊這個連結運行在線演示。

Saltcorn 官方位址：https://github.com/saltcorn/saltcorn

2、Joget DX

Joget DX 是一個低代碼的應用程式構建平台，其目的是説明公司輕鬆實現數位轉型。 Joget DX結合了業務流程自動化管理、工作流程定製和低代碼應用程式開發工具。

Joget DX 可以在雲上和本地運行。 它具有豐富的文檔，易於使用的儀錶板與可視化構建器，支援拖放，並且支援多種操作系統和資料庫。

• Joget DX 官方位址：https://www. joget.com/

3、Digdag

Digdag 是一款開源企業解決方案，旨在實現易於部署、多雲設置和模組化的結構來構建和擴展業務應用。

Digdag 擁有一系列企業功能，包括豐富的管理面板、多語言支援、錯誤處理、配置工具和版本控制工具。

該解決方案採用Java和Node.js開發，它支援 AWS、私有雲、IBM 雲和Digital Ocean。

• Digdag官方位址：https://www. digdag.io/

4、Stackstorm

Stackstorm 與此列表中的任何其他系統不同，它被設計為在一個平臺內連接、管理和監控企業應用的傘專案。

Stackstorm側重於事件驅動的方法、自定義工作流程設計以及使用者角色和許可權。

方法很簡單：事件驅動的自動化，提供感測器、觸發器、每個定義的操作、規則、工作流程和具有豐富記錄系統的審計。

• Stackstorm 官方位址：https://stackstorm.com/

5、CUBA Platform

CUBA Platform是面向企業的開源 的（Apache 2.0許可） 快速應用開發系統。

CUBA Platform配備了數十個工具例如IDE、應用程式開發工作室、CLI命令行介面以及堅實的可擴展基礎設施。

CUBA 平臺具有豐富的外掛程式系統，包含BPM （業務流程管理） 等外掛程式，不過這些外掛程式需要一些時間來構建和安裝。

• BPM外掛程式：https://github.com/cuba-platform/bpm
• CUBA平臺：https://github.com/cuba-platform/cuba

6、Skyve

Skyve是一個開源的業務軟體構建平臺。 它支援無代碼和低代碼的快速應用開發。

Skyve支援不同的資料庫引擎：MySQL、SQL 伺服器和 H2 資料庫引擎。 其開發人員目前正在努力支援PostgreSQL和Oracle。 Skyve提供了豐富的 API 集，以及低代碼開發應用構建精靈。

Skyve平臺由豐富的生態系統組成，其中包括：

1. 企業平臺，
2. 構建器應用程式，採用React Native構建原生移動應用，
3. 與其他第三方服務集成的Skyve總線模組，
4. Skyve Confidence：為TDD提供測試功能
5. Skyve Cortex：
6. Skyve Portal：企業應用的 Web 門戶擴展
7. Skyve CRM：自定義構建Skyve CRM 應用程式
8. Skyve Replica：在分散式 Skyve 實例之間提供無縫同步

• Skyve 官方位址：https://github.com/skyvers/skyve

7、Rintagi

Rentagi是一個聚焦於移動應用的低代碼企業級應用構建平臺。 它也是完全免費和開源的解決方案，這使得它成為中小型公司的完美的解決方案。

Rentagi配備了豐富的複雜工具，用於快速構建應用程式以實現高生產率，它還為移動開發人員提供了豐富的開發人員友好型 API。

• Rintagi官網：https://medevel.com/rintagi/
• Rintagi代碼倉庫：https://github.com/Rintagi/Low-Code-Development-Platform

8、Opexava

OpenXava是一個低代碼應用程式構建平臺，主要側重於生產力、簡單性和可用性。

作為一個使用Java技術構建的跨平台系統，它運行在Linux和Windows伺服器上。 它可能看起來是一個遺留系統，但仍然是許多企業的主要選擇。

OpenXava確保了高生產率、平緩學習曲線、一大批企業功能以及移動和平板電腦的響應式佈局。

OpenXava是一個免費的開源社區版，但企業可以購買不同的額外功能版本。

• OpenXava 官方位址：https://www. openxava.org/en/ate/low-code-development-platform

9、Convertigo

轉換是無代碼/低代碼平臺之間的混合體，它旨在説明業餘/專業開發人員在短時間內創建企業就緒的應用程式和工具。

Convertigo為開發人員提供本地安裝、雲版本和 MBaaS 版本。

Convertigo具有行動應用構建器、可視拖放 UI、低代碼後端、REST/XML 轉換器、REST/JSON 轉換器、管理員控制台等功能。

Convertigo提供完整的 PWA（漸進式 Web 應用程式）、iOS 和安卓移動開發支援。

• Convertigo官方位址：https://www. convertigo.com/

10、Tymly

Tymly是一個業務有限的低編碼平臺，用於創建可擴展的伺服器應用程式。 它以MI許可開源發佈。

Tymly 引入了一個藍圖概念，將業務流程、功能和工作流程封裝到藍圖中。 它擁有生態系統和藍圖庫，可以保護大量的開發資源。

藍圖保存在 JSON 方案中，而數據則存儲在 PostgreSQL 資料庫中。

開發人員可以通過在 JSON 方案中定義其要求、業務功能和工作流程來編寫藍圖。

• Tymly 官方位址：https://medevel.com/tymly-low-code/
• Tymly 代碼倉庫：https://github.com/wmfs/tymly/

11、JUDO

JUDO.code 是另一個面向企業使用的低代碼平臺。 在數據建模、UI 設計和開發方面，JUDO 比此清單中的其他低代碼平臺為開發人員提供了更大的靈活性。

JUDO 適用於 Windows、macOS 和 Linux，提供可安裝包和二進位應用程式包。 （*macOS安裝程序即將推出）。

JUDO.code 門戶為新手提供了豐富的文檔和教程，以及廣泛的使用者指南和應用程式平臺的安裝說明。

• JUDO官方位址：https://www. judo.codes/

12、OpenCatapult

OpenCatapult是一個開源低碼開發自動化平臺。 它通過管理自動化任務，説明DevOps和管理員更好地控制其伺服器。

不幸的是，OpenCatapult 僅適用於 Windows x64 平臺，但開發人員正在計劃在不久的將來發佈 Linux 和 macOS 版本。

• OpenCatapult 官方位址：https://github.com/Polyrific-Inc/OpenCatapult/

13、BudiBase

BudiBase 不僅僅是另一個低代碼平臺，它的目標與其他平臺不同，因為它專注於為開發人員提供工具，以加快一個平臺內的開發、部署和集成過程。

我們試用了一個多禮拜，BudiBase的生產力，可用性和快速部署能力給我們留下了深刻的印象。

• BudiBase 官方位址：https://github.com/Budibase/budibase

14、Generative Objects（GO）平臺

Go 平臺是一家法國公司，致力於企業低代碼開發平臺。 GO平臺側重於更好地控制應用程式生命週期、開發人員之間的協作，以及與其他平臺、桌面、移動和 Web 開發的軟體整合。

Go 平台採用基於模型的應用程式開發方法，在專注於解決方案而非工具時節省時間、金錢和精力。

• GO 官方位址：https://www. generativeobjects.com/

15、Baserow

Baserow是一個引人入勝的工具，用於創建、管理資料庫和即時構建資料庫應用。 Baserow配備了確保高生產率和可用性的功能。

由於Baserow是一個模組化的完整的 REST-API 無頭系統，因此它吸引了移動開發人員的注意，將其用作應用的後端。

Baserow 處於積極開發狀態，因此請繼續關注更多功能。

• Baserow 官方位址：https://gitlab.com/bramw/baserow

16、OS.bee

OS . bee 是企業免費開源平臺，它整合了低代碼和模型驅動的應用開發策略。

OS.bee由一家開發企業 ERP 系統超過 30 年的公司創建。

OS.bee 提供用於創建應用程式數據模型的可視模型和圖表產生器。 該系統由 Java 創建，並提供 Eclipse 安裝和整合。

• OS.bee 官方位址：https://www. osbee.org/home/

17、nuBuilder

nuBuilder 是一個免費開源的 RAD（快速應用開發），用於在幾分鐘內構建企業資料庫應用程式。

nuBuilder是自託管的低代碼工具，具有高度可定製的後端系統。 它使用PHP、HTML、JavaScript與MySQL資料庫。

• nuBuilder官方位址：https://www. nubuilder.com/

18、Metabase

Metabase是一個開源的面向數據的可定製儀錶板，支援廣泛的資料庫後端，如MongoDB、MySQL、PostgreSQL、SQLServer、Oracle等。

Metabase提供了管理資料庫記錄、操縱數據、可操作記錄的可視方法、支持連接、多個聚合、高級篩選和全文搜索。

Metabase是在幾分鐘內創建高生產率和企業可用性的高效資料庫就緒儀錶板的最終解決方案。

Metabase 充滿了令人驚歎的視覺元件，其中包括：圖表、地圖、SVG 向量地圖、分析以及使用者、開發人員和 DevOps 的豐富詳細文檔。

• Metabase 官方位址：https://medevel.com/metabase-low-code/
• Metabase代碼倉庫：https://github.com/metabase/metabase

---

原文連結：Top 18 低代碼平臺 — BimAnt

因為答應要去做這個演講 程式師為什麼不喜歡低代碼

被迫總結輸出一下提綱。 總體上是兩個大方向：

1. 好的工程實踐是有原因的，不會因為"低代碼"了，之前的工程實踐都不再適用
2. 低代碼不是純技術能實現的目標，需要產品和技術一起努力

工程實踐角度

比如說

• 版本管理
• 發佈變更流程
• 單元測試
• 自動化測試
• 調試器
• 代碼提示
• 出錯提示，代碼行號定位
• common reuse principle 等依賴管理原則
• ...

我們把低代碼換個說法叫「最終用戶程式設計」。。 然後把最終使用者看成一個開發團隊。 那低代碼也是一種軟體開發的形式，只是把最終使用者這個軟體開發團隊引入到了軟體開發過程之中了。 傳統的最佳工程實踐都是有價值的，有必要在低代碼這個語境下一一考量一下其意義。

這裡投入不足，很大程度是因為做這些東西成本巨大。 這裡又牽涉到了，什麼情況下值得弄個低代碼出來，多少收益才能抵消成本。

產品和技術協作角度

低代碼建立在「預製件」的基礎上的，但是低代碼沒有說明這些「預製件」是從哪裡來的。 兩種可能：

1. 先有具象的需求，然後逐步歸納出預製件
2. 先有預製件，然後把需求往裡面套

當使用低代碼是純技術行為的時候，技術側就會非常難受。 因為低代碼希望的是需求內在有規範有規律，可以被壓縮成預製件。 但是需求是啥樣，那是產品經理說了算的。

無論是歸納出預製件，還是先有預製件再用預製件表達需求，可能都走得通。 但是都不能是靠技術側去推動產品側，而是一起協作來搞，得有組織和流程的保障。

用 c 語言很難精確寄存器，用java很難控制記憶體，用 vue 很難高頻率刷新 DOM 實現動畫，一項技術總是有其代價。 低代碼也一樣，總是會喪失一些適用範圍和場合。 技術選型的事情應該由解決問題的人，根據問題本身的需求選擇技術方案，而不是被指手畫腳。 使用還是不使用低代碼做為技術方案，應該像其他技術選型一樣讓解決問題的人根據需求來決定。 先有需求，再有解決方案。

有時候不是把所有相似的代碼都歸納成一個函數，就一定就能提效的。 比如搞一個 DSL 解決介面元件聯動問題。 這樣的 DSL 弄出來也就是一個 javascript 的變種。 預製件不是你說那裡可以弄一個出來，就一定可以弄一個出來的。 壓縮是建立在有規律，有冗餘的基礎上的。 如果原來的表述方式已經足夠精簡了，就沒有多少壓縮空間。

程式師提效

我們可以從實現低代碼的技術里尋找提效的手段，但不要把任何提效的努力都打上低代碼的標籤。

所見即所得的可視化編輯。 修改了配置，立即生效。 這樣的低延遲的反饋週期是很好的開發者體驗，值得借鑒過來。 如果程式師所有的修改都可以不經過幾十秒的編譯構建就立即看到反饋，顯然能提升效率。 但這不意味著一定要做動態化解釋執行。 弄一個 JSON 出來解釋執行，渲染介面，不意味著就提效了。 恰恰相反，因為引入了動態化，運行時執行的過程會更複雜，整體的代碼量會變大。

代碼生成是常見的所謂model driven方案的特點。 但是代碼生成相對抽取函數的優點是什麼有沒有想過？ 函數要求自己在一個進程內執行（不能跨進程遷移局部變數），也不能執行太長時間（不能持久化下來，過幾天載入回去接著執行）。 函數同時也是一個編輯時的單元，把相關的邏輯合併到了一個總的索引下。 當我們要把跨進程的邏輯合併到一個編輯時單元下的時候，就沒有辦法使用抽取函數的辦法了。 所以"代碼生成"這個技術，或者"DSL"這個技術，允許的是更大的組織邏輯，分類整理的自由度。

另外一個代碼生成的好處是如果用抽取函數的方式，函數的所有分支都要被閱讀才能知道其行為，而代碼生成可以僅僅關注生成后的代碼實際是啥，而忽略生成器的複雜邏輯。

預製件的願景讓產品需求能夠更有內在一致性。 當程式師和產品經理都認同這幾個功能都應該用預製件拼裝出來的時候，就可以從源頭上減少不必要的產品不一致性導致的額外工作量。 所有的提效手段，最管用的還是砍需求。

如何做出讓程式師喜歡的低代碼

1. 別讓程式師用。 低代碼的用戶應該是 end-user，程式師提效有無數種辦法，別啥都叫低代碼
2. 工程實踐該加的都得有
3. 管控預期，不是什麼需求都可以實現的
4. 讓程式師提供低代碼支援最終用戶程式設計，需要組織和流程保障（對內的低代碼），或者需要商業模式支援（對外的低代碼）

大概提綱就是這樣了，然後就是補充各種例子了

有一個問題一直困擾著很多人，作為程式師，在知名的成熟的大廠，和在小廠乃至創業公司，做代碼開發，區別到底有多大，體現在什麼地方。 我可以講講我個人的體會。

我2009年博士畢業，加入了當時的微軟，做微軟內部的大數據專案。 項目當時還挺保密的，現在當然已經眾所周知了。

我不是一個沒什麼經驗寫程式的人。 博士做的方向是新型的數據倉庫和統計相關技術的結合，為了發表論文也寫過幾個系統，若干萬行c++程式。 所以我一直都以為自己是個"有經驗"的人。

等我真正跨入大廠的時候，還是有點掉下巴的感覺。 微軟給我的第一個感覺是限制多多，非常非常的多。 最基本的限制我給大家列舉一下。

首先，有一個內部的代碼管理系統。 那個時候Git沒那麼流行，微軟用的是自己搞的一套管理代碼的系統。 但是不管怎麼樣，代碼管理的思路基本上還是差不多的。 你不能本地隨意寫代碼就行了。 你需要先checkout一份代碼，等你做完了你的工作以後，再checkin。 Checkout雖然不是什麼難的事情，checkin就老難老難了。

其實，產品開發不是始於代碼。 我們當時在的組用的是敏捷開發，採用scrum的方式，兩週一個sprint。 產品經理先在微軟的專用的管理產品功能的軟體里面對每個功能進行分解，分解到可以開發的功能模組，然後全組根據功能模組的優先順序，在sprint的planning大會上開始選擇誰做什麼。 所有相關的東西都被記錄下來。

與此同時，每個bug的管理也在同一個系統里，bug會被一套完整的流程進行triage，分配給組裡的每個人，然後每個人按時的修復bug。

再次，當我們中間每個人完成了對應功能開發或者bug的修復的時候，這個人需要做很多的事情，才能最終checkin進代碼庫里。 這個過程非常的繁雜。 而對應的每一步，都有軟體產品的支援。

第一步是需要對應的測試用例。 我們會做單元測試，整合測試，性能測試等等，其中單元測試和一部分整合測試都是寫代碼的人負責的，性能測試則由專門的測試團隊負責。 只有代碼沒有測試是不行的。

為了更好的跑測試和開發測試，微軟內部提供了一個測試框架，按照測試框架開發出來的測試，會在整個系統的不同階段被跑。 有一部分是在代碼checkin的時候，作為系統build的一部分。 另外一部分則是每天或者每周定期跑的。 後者通常是一些需要更多資源和時間的測試。 如果有跑失敗的，會通過email的方式發給對應的checkin的負責人那裡。

除了測試以外，開發的軟體需要先build。 build可以簡單的認為對代碼進行編譯，同時跑一部分測試用例。 這個build的過程也非常的冗長而嚴謹。 微軟內部有一系列的工具，每個團隊可以根據自己的需要定製。 這些工具包括對代碼進行編碼風格檢查，是否符合命名規範，是否符合代碼風格。 它們也包含了各種各樣的安全檢查。 比如說有沒有用了什麼軟體包，受不受到什麼漏洞影響，是不是直接在代碼里寫了密碼，信用卡訊息等等。

當然，還有一個必不可缺的步驟是code review。 每次的checkin之前，先需要經過同行的review，需要把review產生的問題一個一個都解決了才能夠checkin。 微軟的工具體系裡，有自動整合review功能的。

除此之外，每個小時，每天，每周的build和跑不同的測試用例都在連續不斷的進行。 有的時候你checkin進去的代碼，也會因此而被打回來，因為在更深度的相容性測試和性能測試里，發現了問題。

這是一套非常複雜的協助開發人員進行全流程管理的工具體系。 微軟有一整個團隊，浩浩蕩蕩很多人在做不同的事情，給內部用，有些產品也賣給外面的人。

由於我剛從學校畢業，對工業界的軟體開發沒經驗，不能真正理解有些東西背後的深意。 這套系統給我的第一感覺是，有點小題大做，拿著高射炮打蚊子。 一方面系統很全面，基本上代碼開發的方方面面都涉及到了，但是在另外一方面，這也讓所有人開發代碼的時候束手束腳的，必須code review，必須過這些安全檢查，必須寫這麼多的test等等。 明明代碼就寫了那麼一點，但是代碼以外的工作卻那麼多。

從學校剛出來的我，很難理解為什麼需要這麼複雜龐大的一套系統，還有那麼大的一個團隊在維繫。 感覺開發效率都低了很多。 不過慢慢的我也越來越習慣於在這樣一套系統里開發軟體。 而且時不時的系統也經常會給我抓出這樣或者那樣的問題。

2014年的時候我決定離開微軟去小一點的公司看看。 我最後加入了一家剛上市的公司。 我加入的時候整個研發團隊大概不到400人。 18個月後，該公司的研發團隊膨脹到1000人。

和微軟比起來，這算是很小的公司了。 但是嚴格意義上來說，這其實也不能算是創業公司，畢竟已經成功上市了。

進到這個公司，給我的感覺有點草台班子。 不是說該有的東西沒有，而是我覺得所有的東西都缺胳膊斷腿的感覺。 新公司依然用scrum，也有自己管理軟體功能和bug的產品，用的是個開源的系統。 總的來說，除了體現在功能少，不好用以外，這個系統和後續的代碼管理，build，測試框架等等，完全沒有打通，有種各自為營的感覺。

公司用的代碼管理系統，買的是另外一家公司的產品。 相對微軟的代碼管理系統來說，功能上先不說，首先的問題是性能。 公司的人員從400到1000的增長過程中，公司代碼管理系統已肉眼可見的速度開始卡頓，掉線，經常罷工。

必須說git的出現極大程度上的解決了這個問題，用了git的都說好。 所以現在的創業公司再也不用擔心代碼管理系統不穩定的問題了。

如果說代碼管理系統的不穩定還不是什麼大問題，最多就是影響工作效率的話，那build和測試就是另外一番天地了。 公司的build系統，是公司的大牛草台班子自己搭的。 為什麼會變成這個樣子，有很多歷史原因。 這個系統有一個特點，薛定諤的貓一般：大部分時候是正常的，有的時候不知道為什麼build就掛掉了，再來一次又正常了。 能修的毛病，估計很多人都試圖去修過。 不能修的一些東西，大家也都養成了用薛定諤對付薛定諤的辦法，多跑幾次，哪次跑通了算哪次。

Code review用的是另外一個開源系統， 和整個build，以及代碼管理系統就完全沒關係了。 Code review本身的不好用暫且不說。 更大的問題是，code review和追蹤產品功能的系統，以及代碼管理的系統都沒有打通，各自為營的話，如果系統出了bug，想要查一查到底哪段代碼導致了什麼事情，程式師就必須在三個系統里三線作戰了，非常的讓人焦頭爛額，頭髮都要多掉幾根。

事情還沒完，公司跑test的系統又是買的另外一個公司的產品，這個產品當然也是不和前面三個系統打通的，所以你想要跑test的話，還得先build好了，再自己到這個新的系統裡面去跑。 公司跑test的系統一如既往的繼承了薛定諤的貓的特性。 很多時候跑著挺好的，但是莫名其妙就會掛，多跑幾次又好了。 這個事情，有的時候是test自己的問題能修，很多時候是系統的穩定性問題。

這些還不算，公司除了自己的build系統的不穩定性以外，公司並沒有能力像微軟那樣對代碼做各種各樣的檢查，不管是程式設計風格還是安全相關的檢查。 公司有次發佈了產品，造成了安全隱患，某些情況下一些使用者可以看到另外一些用戶的數據。 事情影響惡劣。

由於種種原因，公司的這套build相關的框架極大的影響了公司整體的發展。 於是公司決定專門成立一個隊伍，開發自己的build和測試框架，增強穩定性和對代碼安全檢查等等。 這個專案前後兩年時間，投入了40多個人，中間還換了負責人。 結果看起來並不是很好。

我們曾經私底下討論過這個問題。 大廠的一整套對開發人員的生態支持軟體，並不是一蹴而就的，這是長期積累的結果。 這套東西做好了，需要的投入不低。 更重要的，這個體系有很強的複用性。 所以在幾萬人的大廠里投入幾百人搞，不見得是投不起。 但是相反的，一個小企業總共幾百個開發人員，投入幾十個人，這成本就很難負擔得起來，而且效果未必好。

那這樣一來，小企業感覺日子不好過了。 尤其是創業公司，投入多少人能夠搞好這套東西，真說不好。 只能說比較幸運的是Git的出現，起碼解決了代碼管理的問題。

但是我們應該慶幸現在是雲時代。 如果大廠願意，完全可以把自己成熟的生態做成雲服務開放出來。 國內外雲廠商都開始這方面的嘗試了。 比如，阿裡就把內部的一整套DevOps工具免費開放了出來，對外叫做阿裡雲雲效。

使用雲效這樣的雲服務平臺的好處是，作為SaaS雲服務，它開箱即用，企業不需要任何的開發和運維成本。 更重要的是，它是一整套成體系的東西，不管是專案協作、代碼管理、CI/CD、測試管理、製品倉庫等工具都互相打通，而且還和阿裡雲ECS、ACK等產品進行了深度集成，可以自動化部署到雲上。

雖然現在開源社區提供了不同的產品來每個服務，比如說創業公司自己搭git伺服器管理代碼，用Jenkins做CI/CD。 但是回歸問題的本質，東一榔頭西一棒槌的維護各個不同的系統，並不能讓程式師很好的聚焦在真正有意義的事情上。

其次，割裂的工具鏈，不僅數據無法打通，企業也還要維護各自獨立的賬號許可權體系。 相反，使用雲效，註冊一個帳號，就可以快速具備大廠的一站式的DevOps工具鏈， 把精力聚焦在業務開發上，何樂而不為呢。

基於大廠多年的積累，雲效在安全方面也考慮得相當周全。

以雲效代碼管理產品Codeup為例，它不僅對接了阿裡雲完備的高防保護，在產品功能上，也提供了一系列的安全特性。 例如，在數據安全層面，它支持代碼定時備份、代碼加密;在訪問控制上，支援多級許可權管控、IP白名單訪問控制等;在安全審計上，遇到風險問題，你完全可以進行事前監測、事中通知、事後追溯。

值得一提的是，雲效Codeup還內置了豐富的代碼掃描服務，包括源碼漏洞檢測、依賴包漏洞檢測和敏感訊息檢測，一鍵開啟，就可以及時發現最新的安全威脅和漏洞。

雲計算時代是一個改變現實改變未來的時代。 雲效DevOps就是這樣的一款產品，通過將阿里內部的DevOps工具雲服務化，給創業團隊和中小企業提供和大廠一樣方便、安全、高效、全面的體驗。

好消息是，30人以下團隊，直接免費就可以使用雲效一站式的DevOps工具。 前面提到的雲效代碼管理Codeup，更是不限人數、不限容量直接免費用。

感興趣的，可以瞭解一下阿裡雲雲效。

目前國內主流的低代碼開發平臺有：宜搭、雲程、簡道雲、明道雲、氚雲、夥伴雲、道一雲、JEPaaS、華炎魔方、搭搭雲、JeecgBoot 、RuoYi等。 這些平臺各有優劣勢，定位也不同，用戶可以根據自己需求選擇。 如果企業想自主可控，從零開發一個低代碼平臺，如何技術選型呢？

低代碼平臺至少包含表單建模、流程設計、報表可視化、代碼生成器、系統管理、前端UI等元件，我們沒必要重新造輪子，市場上已經有大量的成熟元件，選擇合適的元件進行集成和二次開發，即可自主開發一個低代碼平臺。 以下是以java + vue為開發技術的選型參考。

一、流程引擎選型

市場上比較有名的開源流程引擎有osworkflow、jbpm、activiti、flowable、camunda。 其中：Jbpm4、Activiti、Flowable、camunda四個框架同宗同源，祖先都是Jbpm4，開發者只要用過其中一個框架，基本上就會用其它三個。 開發低代碼平臺、OA系統、BPM軟體均需要流程可視化功能，而流程可視化核心是流程引擎和流程設計器，對於市場上如此多的開源流程引擎，哪個功能和性能好，該如何選型呢？

1、Osworkflow

Osworkflow是一個輕量化的流程引擎，基於狀態機機制，資料庫表很少，Osworkflow提供的工作流構成元素有：步驟（step）、條件（conditions）、迴圈（loops）、分支（spilts）、合併（joins）等，但不 支援會簽、跳轉、退回、加簽等這些操作，需要自己擴展開發，有一定難度，如果流程比較簡單，osworkflow是很號的選擇，筆者在2008年給某大型國企集團開發OA系統，就是基於Osworkflow，至今仍穩定運行，性能也很高。 官方網站：http://www. opensymphony.com/osworkflow/

2、JBPM

JBPM由JBoss公司開發，目前最高版本JPBM7，不過從JBPM5開始已經跟之前不是同一個產品了，JBPM5的代碼基礎不是JBPM4，而是從Drools Flow重新開始，基於Drools Flow技術在國內市場上用的很少，所有不建議選擇jBPM5以後版本，jBPM4誕生的比較早，後來JBPM4創建者Tom Baeyens離開JBoss後，加入Alfresco後很快推出了新的基於jBPM4的開源工作流系統Activiti， 另外JBPM以hibernate作為數據持久化ORM也已不是主流技術。 筆者在2012年開發某集團BPM平臺時，選擇的就是JBPM4.4版本，也是4系列的最後一個版本，進行了大量的擴展開發，才實現臺灣特色的流程需求。 現在時間節點選擇流程引擎，JBPM不是最佳選擇。 官方網站：https://www. jbpm.org/

3、Activiti

activiti由Alfresco軟體開發，目前最高版本activiti 7。 activiti的版本比較複雜，有activiti5、activiti6、activiti7幾個主流版本，選型時讓人暈頭轉向，有必要先瞭解一下activiti這幾個版本的發展歷史。 activiti5和activiti6的核心leader是Tijs Rademakers，由於團隊內部分歧，在2017年時Tijs Rademakers離開團隊，創建了後來的flowable， activiti6以及activiti5代碼已經交接給了Salaboy團隊， activiti6以及activiti5的代碼官方已經暫停維護了， Salaboy團隊目前在開發activiti7框架，activiti7內核使用的還是activiti6，並沒有為引擎注入更多的新特性，只是在activiti之外的上層封裝了一些應用。 結論是activiti謹慎選擇。 官方網站：https://www. activiti.org/

4、flowable

flowable基於activiti6衍生出來的版本，flowable目前最新版本是v6.6.0，開發團隊是從activiti中分裂出來的，修復了一眾activiti6的bug，並在其基礎上研發了DMN支援，BPEL支援等等，相對開源版，其商業版的功能會更強大。 以flowable6.4.1版本為分水嶺，大力發展其商業版產品，開源版本維護不及時，部分功能已經不再開源版發佈，比如表單生成器（表單引擎）、歷史數據同步至其他數據源、ES等。 Flowable 是一個使用 Java 編寫的輕量級業務流程引擎，使用 Apache V2 license 協定開源。 2016年10月，Activiti工作流引擎的主要開發者離開Alfresco公司並在Activiti分支基礎上開啟了 Flowable 開源專案。 基於 Activiti v6 beta4 發佈的第一個 Flowable release 版本為6.0。 Flowable 專案中包括 BPMN（Business Process Model and Notation）引擎、CMMN（Case Management Model and Notation）引擎、DMN（Decision Model and Notation）引擎、表單引擎（Form Engine）等模組。 官方網站：https://flowable.com/open-source/

5、Camunda

Camunda基於activiti5，所以其保留了PVM，最新版本Camunda7.15，保持每年發佈2個小版本的節奏，開發團隊也是從activiti中分裂出來的，發展軌跡與flowable相似，同時也提供了商業版，不過對於一般企業應用，開源版本也足夠了，詳細見：https://blog.csdn.net/wxz258/article/details/10904373。 官方網站：https://docs.camunda.org/manual/7.15/。 筆者強烈推薦camunda流程引擎，並在雲程低代碼平臺中使用了camunda，功能和性能表現穩定。

選擇camunda的理由：

（1）通過壓力測試驗證Camunda BPMN引擎性能和穩定性更好。 詳細見：https://blog.csdn.net/wxz258/article/details/109030329

（2）功能比較完善，除了BPMN，Camunda還支援企業和社區版本中的CMMN（案例管理）和DMN（決策自動化）。 Camunda不僅帶有引擎，還帶有非常強大的工具，用於建模，任務管理，操作監控和使用者管理，所有這些都是開源的。 詳細見：https://blog.csdn.net/wxz258/article/details/109121092

二、流程設計器選型

對於低代碼平臺中的流程可視化，流程設計器是重要的支撐工具，目前市場上比較主流的流程設計器有bpmn-js、mxGraph、Activiti-Modeler、flowable-modeler、easy-flow、bpmn2-modeler外掛程式等。

1、bpmn-js

bpmn-js 是 BPMN 2.0 渲染工具包和 Web 模型。 bpmn-js 正在努力成為 Camunda BPM 的一部分。 bpmn-js 使用 Web 建模工具可以很方便的構建 BPMN 圖表，可以把 BPMN 圖表嵌入到你的專案中，容易擴展。 bpmn-js是基於原生js開發，支援集成到vue、react等開源框架中。

官方網站：https://bpmn.io/

2、mxGraph

mxGraph是一個強大的JavaScript流程圖前端庫，可以快速創建互動式圖表和圖表應用程式，國內外著名的ProcessOne和draw.io都是使用該庫創建的強大的在線流程圖繪製網站. 由於mxGraph是一個開放的js繪圖開發框架，我們可以開發出很炫的樣式，或者完全按照專案需求定製。 官方網站：http://jgraph.github.io/mxgraph/

3、Activiti-Modeler

Activiti 開源版本中帶了web版流程設計器，在Activiti-explorer專案中有Activiti-Modeler，優點是集成簡單，開發工作量小，缺點是介面不美觀，用戶體驗差。

4、flowable-modeler

flowable開源版本中帶了web版流程設計器，展示風格和功能基本跟Activiti-Modeler一樣，優點是集成簡單，開發工作量小，缺點是介面不美觀，用戶體驗差。

5、easy-flow

碼雲上開源的流程設計器，沒有深入研究，感覺離真正的BPMN流程圖設計差距較大，不過至少有個框架。

https://gitee.com/xiaoka2017/easy-flow?_from=gitee_search

6、Eclipse外掛程式bpmn2-modeler

C/S版本的流程設計器，如果沒有強調基於瀏覽器設計流程圖，也可以考慮Eclipse外掛程式版流程設計器bpmn2-modeler。 官方位址：http://www. eclipse.org/bpmn2-modeler/

結論：推薦大家使用camunda（流程引擎）+bpmn-js（流程設計器）組合，筆者在雲程BPM中實戰驗證，功能比flowable、activiti流程引擎強大，性能和穩定性更好，體驗系統：http://www.yunchengxc.com。

三、表單設計器選型

1、form-generator

form-generator 是基於Element UI表單設計及代碼生成器，可將生成的代碼直接運行在基於Element的vue專案中;也可導出JSON表單，使用配套的解析器將JSON解析成真實的表單。

官方位址：https://gitee.com/mrhj/form-generator？_from=gitee_search

2、vue-form-making

vue-form-making基於 vue 和 element-ui 實現的可視化表單設計器，使用了最新的前端技術棧，內置了 i18n 國際化解決方案，可以讓表單開發簡單而高效。

https://gitee.com/gavinzhulei/vue-form-making?_from=gitee_search

3 、k-form-design

k-form-design設計器布局參考form-generator專案，基於vue和ant-design-vue實現的表單設計器，樣式使用less作為開發語言，主要功能是能通過簡單操作來生成配置表單，生成可保存的JSON數據，並能將JSON還原成表單，使表單開發更簡單更快速

https://gitee.com/kcz66/k-form-design?_from=gitee_search

四、vue框架選型

1、ElementUI

Element，一套為開發者、設計師和產品經理準備的基於 Vue 2.0 的桌面端元件庫

https://element.eleme.cn/#/zh-CN

2、Ant Design Vue

螞蟻金服出品，Ant Design 作為一門設計語言面世，經歷過多年的反覆運算和積累，它對UI的設計思想已經成為一套事實標準，受到眾多前端開發者及企業的追捧和喜愛，也是React開發者手中的神兵利器。 希望 ant-design-vue 能夠讓 Vue 開發者也享受到 Ant Design 的優秀設計。

ant-design-vue 是 Ant Design 的 Vue 實現，元件的風格與 Ant Design 保持同步，元件的 html 結構和 css 樣式也保持一致，真正做到了樣式 0 修改，元件 API 也盡量保持了一致。 Ant Design Vue 致力於提供給程式師愉悅的開發體驗。

https://www. antdv.com/docs/vue/introduce-cn/

3、Vue Antd Admin

Ant Design Pro 的 Vue 實現版本，開箱即用的中後台前端/設計解決方案。 開源免費用。

https://gitee.com/iczer/vue-antd-admin#https://iczer.gitee.io/vue-antd-admin

4、vue-admin-beautiful

採用vue + element-ui 前後端分離開發模式、面向全螢幕尺寸的回應式適配能力（相容電腦、手機、平板），有vue2和vue3兩個版本，分開源版本和付費版，適合正在以及想使用 element-ui/element-plus 開發，前端開發經驗 1 年+，熟悉 Vue.js 技術棧，使用它開發過幾個實際項目的團隊。

官方位址：https://github.com/chuzhixin/vue-admin-beautiful

5、Avue.js

Avue.js2.0是基於現有的element-ui庫進行的二次封裝，簡化一些繁瑣的操作，核心理念為數據驅動視圖，主要的元件庫針對table表格和form表單場景，同時衍生出更多企業常用的元件，達到高複用，容易維護和擴展的框架，同時內置了豐富了數據展示元件，讓開發變得更加容易，avue-cli是後台模組。 企業版本收費。

官方網站：https://avuejs.com

五、系統管理元件選型

1、若依RuoYi-Vue

基於SpringBoot，Spring Security，JWT，Vue & Element 的前後端分離許可權管理系統，目前是碼雲開源裡很火的一個框架，優點是提供了系統管理常用的功能，比如：組織管理、角色管理、日誌管理等，設計比較簡單，功能比較聚焦，代碼好讀懂，缺點是電子錶單、流程引擎收費。

https://gitee.com/y_project/RuoYi-Vue

2、jeecg-boot

JeecgBoot 是一款基於代碼生成器的 低代码 開發平臺！ 前後端分離架構 SpringBoot2.x，SpringCloud，Ant Design&Vue，Mybatis-plus，Shiro，JWT，支援微服務。 優點是提供了組織管理、角色管理、日誌管理等系統管理常用的功能，元件比ruoyi多，涉及面比較廣，代碼生成器功能比較強大，但代碼比ruoyi複雜，完全讀懂可維護有難度，缺點是電子表單、流程引擎收費。

https://gitee.com/jeecg/jeecg-boot

3、OPSLI

該平臺自帶了功能表管理、角色管理、組織機構、租戶管理、字典管理、配置管理、系統設置等系統管理常用模組。

官方位址：http://demo.opsli.arcinbj.com/#/index

六、可視化圖表選型

相比於傳統手工定製的圖表與數據儀錶盤，圖表可視化製作平台的出現，可以打破抵消的定製開發， 數據分散的問題，通過數據採集、清洗、分析到直觀實時的數據可視化展現，能夠多方位、多角度、全景展現各項指標，實時監控，動態一目了然。

可視化圖表庫技術選型，目前筆者調研的已知主流可視化庫有：

• echart 一個基於 JavaScript 的老牌開源可視化圖表庫
• D3.js 一個數據驅動的可視化庫， 可以不需要其他任何框架獨立運行在現代瀏覽器中，它結合強大的可視化元件來驅動 DOM 操作
• antv 包含一套完整的可視化元件體系
• Chart.js 基於 HTML5 的 簡單易用的 JavaScript 圖表庫
• metrics-graphics 建立在D3之上的可視化庫， 針對可視化和布置時間序列數據進行了優化
• C3.js 通過包裝構造整個圖表所需的代碼，使生成基於D3的圖表變得容易

我們使用以上任何一個庫都可以實現我們的可視化大屏搭建的需求， 各位可以根據喜好來選擇.

七、其它常用後端技術棧

l Java EE 8+ （軟體構建、運行需要）

l Apache Maven 3.x （軟體構建需要）

l Redis 3.2+ （軟體運行需要）

l nginx 1.20 （Http服務，部署前端需要）

l Mysql 5.7+ （軟體運行需要）

l Spring Boot 2.3.x （主框架）

l Mybatis-plus 3.3.x （持久化）

l Druid 1.1.x（資料庫連接池）

l Apache Shiro 1.7 （許可權）

l JWT 3.7.0 （登錄驗證加密token）

l Quartz 2.3.x（定時任務）

l Easypoi 4.2.x（Excel導入導出）

l Swagger2（在線API）

l Slf4j （日誌介面）

l WebSocket （即時通訊）

l Freemarker 2.3.30 （範本引擎）

l camunda 7.11 （流程引擎）

l minio 4.x （分散式文件存儲）

1 Maven 項目構建依賴管理

Maven 翻譯為"專家"、"內行"，是 Apache 下的一個純 Java 開發的開源專案。 基於項目物件模型（縮寫：POM）概念，Maven利用一個中央訊息片斷能管理一個專案的構建、報告和文檔等步驟。

Maven 是一個專案管理工具，可以對 Java 專案進行構建、依賴管理。 本系統採用Maven來管理專案，並且建立的是多模組專案，讓每個模塊獨立，高內聚，低耦合. 不同模組之間保持自己的完整性。 可以互相不干擾. 方便以後的維護開發。

2 Redis 緩存

Redis是一個開源的使用ANSI C語言編寫、遵守BSD協議、支持網路、可基於記憶體亦可持久化的日誌型、Key-Value資料庫，並提供多種語言的API。

它的優點如下：速度快，完全基於記憶體，使用C語言實現，網路層使用epoll解決高併發問題，它的單線程模型避免了不必要的上下文切換及競爭條件。

3 Ngnix Http服務和反向代理服務

什麼是Nginx？ Nginx是一個高性能的HTTP和反向代理伺服器，也是一個IMAP/POP3/SMTP這些郵件協定的代理伺服器，高可靠性，支援高併發性，低系統資源消耗性。 簡單來說，當一台伺服器的單位時間內的訪問量越大時，伺服器壓力就越大，大到超過自身承受能力時，伺服器就會崩潰。 為了避免伺服器崩潰，讓使用者有更好的體驗，以可使用Ngnix負載均衡來分擔伺服器壓力。

4 mysql資料庫

MySQL是一個關係型資料庫管理系統，由瑞典MySQL AB 公司開發，屬於 Oracle 旗下產品。 MySQL 是最流行的關係型資料庫管理系統之一，在 WEB 應用方面，MySQL是最好的 RDBMS （Relational Database Management System，關係資料庫管理系統） 應用軟體之一。

MySQL是一種關係型資料庫管理系統，關係資料庫將數據保存在不同的表中，而不是將所有數據放在一個大倉庫內，這樣就增加了速度並提高了靈活性。

MySQL所使用的 SQL 語言是用於存取資料庫的最常用標準化語言。 MySQL 軟體採用了雙授權政策，分為社區版和商業版，由於其體積小、速度快、總體擁有成本低，尤其是開放源碼這一特點，一般中小型網站的開發都選擇 MySQL 作為網站資料庫。

5 SpringBoot框架

SpringBoot是由Pivotal團隊提供的全新框架，其設計目的是用來簡化新Spring應用的初始搭建以及開發過程。 該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置。 通過這種方式，Spring Boot致力於在蓬勃發展的快速應用開發領域（rapid application development）成為領導者。

SpringBoot的核心就是簡化配置，快速開發，非常符合我們公司的開發理念。 讓開發人員只關心業務的實現而無需擔心開發時繁瑣的配置問題，在搭配上代碼生成器，即使不懂代碼也能開發出自己想要的功能。 SpringBoot框架有很好的拓展性，可以將SpringBoot專案拆分為SpringCloud微服務。

6 Mybatis-Plus 數據持久化框架

Mybatis是當前最火熱的java持久層框架之一，它不僅是一款優秀的持久層框架，還支援定製化 SQL、存儲過程以及高級映射。 Mybatis避免了幾乎所有的JDBC代碼和手動設置參數以及獲取結果集。 Mybatis可以使用簡單的 XML或注解來配置和映射原生訊息，將介面和Java的POJOs（Plain Ordinary Java Object，普通的Java物件）映射成資料庫中的記錄。

而Mybatis-Plus 在 Mybatis 的基礎上進行擴展，只做增強不做改變，引入 Mybatis-Plus 不會對您現有的 Mybatis 構架產生任何影響，而且 MP 支援所有 Mybatis 原生的特性。

7 Druid資料庫連接池

Druid是一款開源的JDBC連接池、監控元件。 可以監控資料庫訪問性能，Druid內置提供了一個功能強大的StatFilter外掛程式，能夠詳細統計SQL的執行性能，這對於線上分析資料庫訪問性能有説明。

8 Shiro 許可權控制

Apache Shiro是一個強大且易用的Java安全框架，執行身份驗證、授權、密碼和會話管理。 使用Shiro的易於理解的API，您可以快速、輕鬆地獲得任何應用程式，從最小的移動應用程式到最大的網路和企業應用程式。 使用Shiro可以控制頁面按鈕許可權、功能表訪問許可權、後台服務介面許可權。 在前後端分離架構中，可以和jwt配合使用。

9 JWT 登錄token

Json web token （JWT）， 是為了在網路應用環境間傳遞聲明而執行的一種基於JSON的開放標準（（RFC 7519）.該token被設計為緊湊且安全的，特別適用於分散式網站的單點登錄（SSO）場景。 JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的使用者身份訊息，以便於從資源伺服器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明訊息，該token也可直接被用於認證，也可被加密。 在前後端分離架構中，可以和shiro配合使用。

10 Quartz 定時任務

Quartz框架是一個全功能、開源的任務調度服務，可以集成幾乎任何的java應用程式—從小的單片機系統到大型的電子商務系統。 Quartz可以執行上千上萬的任務調度。 雲程平臺集成了任務調度功能，開發了可視化介面，用簡單的操作來實現自己所需要的任務調度。

11 EasyPoi office文檔處理

雲程平臺office文件處理採用了EasyPoi 這個POI 工具類來做檔的快速導入導出，讓一個沒見接觸過poi的人員 就可以方便的寫出Excel匯出，Excel範本導出，Excel導入，Word範本導出，通過簡單的注解和範本 語言（熟悉的表達式語法），完成以前複雜的寫法。 也非常匹配簡單、快速開發的理念。

此外，使用OpenOffice來做文檔的預覽功能，OpenOffice是一個開源辦公套件，它的文件處理可以實現office系列文檔ppt，pptx，xls，xlsx，doc， docx都能夠在線預覽。

12 Swagger2 在線API

Swagger2是一個規範和完整的框架，用於生成、描述、調用和可視化Restful風格的web服務。

現如今，前後端分離已經逐漸成為互聯網專案一種標準的開發方式，前端與後端交給不同的人員開發，但是項目開發中的溝通成本也隨之升高，這部分溝通成本主要在於前端開發人員與後端開發人員對WebAPI介面的溝通，Swagger2 就可以很好地解決，它可以動態生成Api介面文檔，降低溝通成本，促進專案高效開發。 可以使用 Swagger2 +knife4j-ui進行API發佈和管理。

13 Slf4j 日誌介面

Slf4j是一個日誌介面，自己沒有具體實現日誌系統，只提供了一組標準的調用api，這樣將調用和具體的日誌實現分離，使用Slf4j后有利於根據自己實際的需求更換具體的日誌系統。

比如，之前使用的具體的日誌系統為log4j，想更換為logback時，只需要刪除log4j相關的jar，然後加入logback相關的jar和日誌配置檔即可，而不需要改動具體的日誌輸出方法，試想如果沒有採用這種方式，當你的系統中日誌輸出有成千上萬條時，你要更換日誌系統將是多麼龐大的一項工程。

如果你開發的是一個面向公眾使用的元件或公共服務模組，那麼一定要使用Slf4j的這種形式，這有利於別人在調用你的模組時保持和他系統中使用統一的日誌輸出。

14 WebSocket 即時通訊

雲程平臺即時通訊採用WebSocket協定，它是 HTML5 開始提供的一種在單個 TCP 連接上進行全雙工通訊的協定。 簡單來說，使用WebSocket使得用戶端和伺服器之間的數據交換變得更加簡單，並且能有效節約伺服器資源和頻寬。 WebSocket也為本系統在web端、app端、小程式端、H5端都實現了消息即時互通，即時推送功能。

15 Freemarker範本引擎

FreeMarker 是一款範本引擎： 即一種基於範本和要改變的數據， 並用來生成輸出文字（HTML網頁，電子郵件，配置檔，原始程式碼等）的通用工具。 它不是面向最終使用者的，而是一個Java類庫，是一款程式師可以嵌入他們所開發產品的元件。 範本編寫為FreeMarker Template Language （FTL）。

低代碼平臺可以採用Freemarker範本引擎來進行代碼生成器範本的開發，集成了前後端範本，支援全頁面操作生成自己想要的功能，包括單表的增刪改查，多表關聯的開發，還有工作流程表單的開發以及移動端的介面功能生成。 有效降低軟體開發投入成本，使開發變得簡單。

16 camunda流程引擎

Camunda流程引擎分社區版和企業版，社區版實際上是開源版，是Apache2.0協議，企業版實際上是商業收費版本，需要購買授權才能使用。 Camunda是一個基於Java的框架，支持用於工作流和流程自動化的BPMN、用於案例管理的CMMN和用於業務決策管理的DMN。 Camunda包括了流程設計器（Modeler）、流程引擎（Engine）、API介面（REST/Java API）、任務清單（TaskList）、流程管理控制台（Cockpit）、系統管理工具（Admin）。 在Camunda商業產品中還包括了流程監控預警工具（Optimize）、流程協同設計工具（Cawemo）。 Camunda流程設計器，支援兩種模式，一種是富用戶端的流程建模工具Camunda Modeler，需要在用戶端安裝;另一種是基於瀏覽器的流程設計器http://bpmn.io，這兩款軟體均開源。 雲程平臺沒有重複發明輪子，對業界主流的開源流程引擎osworkflow、jbpm、activiti、flowable、camunda等進行了對比驗證，發現camunda在功能和性能方面都比較優秀，最終選擇了camunda流程引擎。

詳細參考：https://blog.csdn.net/wxz258/article/details/109121092

17 minio 分散式文件存儲

Minio是一個開源的物件存儲服務元件，非常適合存儲大量非結構後的數據，比如圖片、視頻、文檔等。 Minio相容Amason的S3分散式物件存儲專案，採用Golang實現，客戶端支援Java，Python，Javacript， Golang語言。 對於中小型企業，如果不選擇存儲上雲，那麼 Minio 是個不錯的選擇，麻雀雖小，五臟俱全。 當然 Minio 除了直接作為物件存儲使用，還可以作為雲上物件存儲服務的閘道層，無縫對接到 Amazon S3、MicroSoft Azure。

八、其它常用前端技術棧

l vue 2.6.x （vue主框架）

l ant-design-vue 1.7.x （vue元件）

l less 3.9.x （css管理工具）

l Webpack 4.x （前端工程構建打包）

l Node 8.9.x （前端工程開發運行環境）

l Npm 3.x （前端工程包管理員）

l Yarn （前端工程包管理員）

l AntV （圖表元件）

l Vant 2.11.x（移動端框架）

l Uni-app （小程式框架）

1 Vue框架

Vue.js是一套構建使用者介面的漸進式框架。 與其他重量級框架不同的是，Vue 採用自底向上增量開發的設計。 Vue的核心庫只關注視圖層，並且非常容易學習，非常容易與其它庫或已有專案整合。 另一方面，Vue 完全有能力驅動採用單檔元件和Vue生態系統支援的庫開發的複雜單頁應用。

https://cn.vuejs.org/

2 Ant Design Vue

Ant Design Vue 是使用 Vue 實現的遵循 Ant Design 設計規範的高品質 UI 元件庫，用於開發和服務於企業級中後台產品。

https://www. antdv.com/docs/vue/introduce-cn/

3 less css管理工具

Less 是一門 CSS 預處理語言，它擴展了 CSS 語言，增加了變數、Mixin、函數等特性，使 CSS 更易維護和擴展。 Less 可以運行在 Node 或瀏覽器端。

http://lesscss.cn/

4 Webpack 前端構建工具

Webpack 是一個前端資源載入和打包工具。 所謂的模組就是在平時的前端開發中，用到一些靜態資源，如JavaScript、CSS、圖片等檔，webpack就將這些靜態資源文件稱之為模組。 webpack支援AMD和CommonJS，以及其他的一些模塊系統，並且相容多種JS書寫規範，可以處理模組間的依賴關係，所以具有更強大的JS模組化的功能，它能對靜態資源進行統一的管理以及打包發佈。

5 Node.js 前端開發運行環境

Node.js 是一個基於 Chrome V8 引擎的 JavaScript 運行環境。 Node.js 使用了一個事件驅動、非阻塞式 I/O 的模型，使其輕量又高效。 Node.js 的包管理器 npm，是全球最大的開源庫生態系統。 Vue開發需要安裝node環境。

http://nodejs.cn/

6 npm js包管理器

npm 為你和你的團隊打開了連接整個 JavaScript 天才世界的一扇大門。 它是世界上最大的軟體註冊表，每星期大約有 30 億次的下載量，包含超過 600000 個 包（package） （即，代碼模組）。 來自各大洲的開源軟體開發者使用 npm 互相分享和借鑒。 包的結構使您能夠輕鬆跟蹤依賴項和版本。

https://www. npmjs.cn/

7 yarn js包管理器

Yarn就是一個類似於npm的包管理工具，它是由facebook推出並開源。
與npm相比，yarn有著眾多的優勢，主要的優勢在於：速度快、離線模式、版本控制。

npm用下來比較強的一個痛點就是：當包的依賴層次比較深時，版本控制不夠精確。 會出現相同package.json，但不同人的電腦上安裝出不同版本的依賴包，出現類似我的電腦上可以運行，別的電腦上不行的bug很難查找。 可以使用npm-shrinkwrap來實現版本固化，版本訊息會寫入 npm-shrinkwrap.json檔中，但它畢竟不是npm的標準配置。

yarn天生就能實現版本固化。 會生成一個類似npm-shrinkwrap.json的yarn.lock檔，而檔內會描述包自身的版本號，還會鎖定所有它依賴的包的版本號，yarn.lock存儲著每個包的確切依賴版本，能確保從本地開發到生產環境，所有機器上都有精確相同的依賴版本。

8 AntV 數據可視化元件

AntV 是一個數據可視化專案，也是一個團隊，螞蟻金服數據可視化團隊，一群有愛有夢的人，懷揣「讓人們在數據世界里獲得視覺化思考能力」的夢想前行， 希望成就智慧時代全球領先的數據可視化解決方案，滿足與日俱增的數據洞察需求。
AntV 目前覆蓋了統計圖表、移動端圖表、圖可視化、地理可視化、2D 繪圖引擎和智慧可視化多個領域，主要包含 G2、G6、F2、L7 以及一套完整的圖表使用和設計規範。 得益於豐富的業務場景和使用者需求挑戰，AntV 經歷多年積累與不斷打磨，已支撐起阿裡集團內外 20000+ 業務系統，通過了日均千萬級 UV 產品的嚴苛考驗，是阿裡經濟體數據可視化最重要的基礎設施。

https://gitee.com/antv

9 uni-app 小程序開發框架

uni-app 是一個使用 Vue.js 開發所有前端應用的框架，開發者編寫一套代碼，可發佈到iOS、Android、H5、以及各種小程式（微信/支付寶/百度/頭條/QQ/釘釘/淘寶）、快應用等多個平臺。

10 Vant h5開發框架

Vant 是讚前端團隊維護的移動端元件庫，提供了一整套 UI 基礎元件和業務元件。 輕量、可靠的移動端 Vue 元件庫，採用 MIT 開源協定， 目前github star 數9k+，是有讚的一套開源元件庫。 通過 Vant，可以快速搭建出風格統一的頁面，提升開發效率。 目前已有近 60+ 個元件，這些元件被廣泛使用於有讚的各個行動端業務中。 缺點是不支援小程式。

九、總結

自主開發低代碼平臺的難點是技術元件眾多，如何掌握並有效集成是難點，尤其是流程引擎和表單引擎技術難度較大，沒有從事過BPM開發的團隊很難搞定，開發失敗的風險比較大。 更合理的捷徑是採購市場上成熟的低代碼平臺源碼，再進行二次開發完善，難度和風險比從頭自主開發小很多。

雲程是一款基於SpringBoot+VUE的雲原生低代碼開發平臺。 採用微服務、前後端分離架構，基於可視化流程建模、表單建模、報表建模工具，零代碼快速構建雲端業務應用 ，平臺即可當地語系化部署，也可基於K8S雲原生部署。 雲程平臺也是一款專業的BPM軟體，即可獨立部署，支撐企業級端到端流程落地，也可嵌入到您的OA、ERP等系統中，作為流程引擎元件使用。

體驗環境：雲端程低代碼平台體驗環境http://www. yunchengxc.com

雲程平臺研發團隊核心成員有10年以上的軟體研發經驗，聚焦於低代碼平臺和流程引擎等中間件產品研發，可交付原始碼，也可定製開發。