無代碼編程時代下，程序員要失業了？

作者 | Phodal

責編 | 伍杏玲

【CSDN 編者按】“中台之後，便是無代碼編程。”無代碼編程是什麽？開發流程是怎麽樣的？有何優缺點？

無代碼編程時代來了，就不需要程序員編寫代碼了嗎？下面作者將跟大家聊聊無代碼編程的那些事兒。

規模化的組織，經常要面臨這樣的挑戰：每個應用的基礎設施是相同的，部分的代碼也是相同的，甚至於它們可能只是數據模型不同而已。結果卻導致了，他/她們要一次又一次地重新編寫一個應用。對於一個新的應用而言，它需要對接大量的三方（非自己團隊）服務。服務之間的不斷變化 ，導致了對應的使用方也需要發生變化。不斷變化的業務，導致了前台的設計不斷變化。為了應對快速談的的前台服務，後台便誕生了中台，以提供快速的響應能力。而隨著中台進一步沉澱，從某種形式上趨於穩定，而前台仍然需要快速地響應能力。

於是乎，作為一個前端開發人員，我們不斷提煉和複用代碼，想著的模式在之前的文章已提到了：

腳手架

組件庫

模式庫

模板和模板應用

對應的，我們還創建了一系列的 CLI、工具集、編程器插件以及設計系統，以完成整個系統的快速開發。然而，我們還缺少一套有效的工具，來統一化的管理這些工具。

換句話來說，就是：我們需要一個前端的中台，它便是無代碼/低代碼編程。

什麽是無代碼編程？

無代碼/低代碼是一種創建應用的方法，它可以讓開發人員使用最少的編碼知識，來快速開發應用程序。它可以在圖形界面中，使用可視化建模的方式，來組裝和配置應用程序。開發人員可以直接跳過所有的基礎架構，隻關注於使用代碼來實現業務邏輯。

當然，從開發人員的角度來看，降低代碼量，可能是：

框架本身處理了複雜性。畢竟 “複雜度同力一樣不會消失，也不會憑空產生，它總是從一個物體轉移到另一個物體或一種形式轉為另一種形式。”

代碼生成減少了工作量。大量的複製、粘貼需要更多的時間。

流程

只是憑借這個概念，我們是無法理解無代碼編程的。於是，我畫了一張圖來展示相應的架構和流程：

依照我的觀點來看，我將無代碼編程分為了兩部分：

用於構建 UI 的編輯器——一種在線的拖拽式 UI 設計和頁面構建工具

用於編寫業務邏輯的流編輯器——通過流編程的方式來編寫業務代碼（多數是對於數據的處理）

UI 編程器

為了設計出我們的 UI 構建器，我們需要準備好一系列的基礎設施：

UI 編程器。用於拖拽式設計 UI。

空白腳手架。一個帶有完整的應用生命周期的項目，但是它是一個空白的項目——用於我們在構建 UI 的過程中，隨時隨地的添加組件和代碼。

設計系統。我們需要一個完整的組件庫，大量的頁面模板，以及一定數量的模板應用，減少相應的開發工具量。

代碼片段集。它將設計系統中的組件庫進一步實例化成代碼段，在完成編輯後通過 CLI 來動態編輯代碼。

DSL（領域特定語言，可選）。中間生成物，用於隔離框架與設計。

流編程器

流編程器。用於拖拽式、輸入編寫業務代碼。

後端服務。如果不能提供現成的後端服務，則需要擁有一個標準的 API 規範，以及相應的 mock server。

模式庫。包含相應的業務處理代碼，如通用的登錄、數據獲取、UI 互動等。

DSL（領域特定語言，可選）。同上

當然了，我們還需要能實時預覽構建出來的應用。隨後，我們執行了構建，而後構建出了一個半成品應用。開發人員只需要在它的基礎上開發應用即可。而在開發人員開發的過程中，我們可以設計一系列的工具，來幫助開發人員更快速地構建應用。

編輯器插件。包含設計系統、模式庫等的自動完成代碼，以及組織內部常用的代碼庫。

調試工具。對於混合類型的應用而言，我們還需要一個開發工具來快速構建應用。

從上述的流程上來看，無代碼編程還具有以下的特點：

拖放式界面。又或者是可視化模型——基於節點和箭頭。

基於視覺的設計。

可擴展的設計。如對於插件、插件商店，社區等一系列的支持。

跨平台功能。支持 PC Web 應用開發，支持移動應用構架等。

強大的部署後。即平台包含著整個應用的生命周期。

擁有豐富的集成支持。可以隨意的找到需要的組件，以及對應的後台服務。

配置化。它也意味著大量的自定義配置。

自製的領域特定語言（可選）。用於構建時優化。

優缺點

相應的，它具有以下的一些優點：

高效。不用多說，節省時間和開發成本。

有限的 Bug，安全性。

低成本。其所需的預算非常有限。

易用（取決於設計）。

開發速度更快。

開發過程中的 AI 。

維護成本低。

對應的相應的缺點有：

仍然需要編程技能。

受限的自定義能力。

可擴展性成了新的問題。

集成受限。

就當前而言，低代碼開發平台通常分為兩大類：

對於外部：製作簡單的產品，如網絡移動應用程序

對於內部：為您的團隊或企業創建業務應用程序

諸如隻使用CRUD、表單、驗證、簡單聚合、分頁等簡易的服務。最常見的例子就是表單構建了，諸如金數據這樣的應用，便是可以直接通過拖拽元素來生成，相應的開源實現有 jQuery Form Builder。

對於開發人員來說，我們只需要定義好數據模型，再通過拖拽來決定元素的位置即可。從這種角度來看，只要能使用 Serverless 構建的應用和服務，都可以直接使用低代碼開發模式。

開發流程對比

從我們的理解來看，傳統應用的開發流程是：

分析、設計、確認、規劃需求。

設計系統架構。

搭建前後端項目。選擇技術棧、從零開始搭建或者從腳手架中創建。

搭建持續集成。

創建線框圖和高保真原型。

設計數據模型，定義前後端契約，即 API URI、方法、資料欄等。

前後端實現業務邏輯。

前端實現 UI 頁面。

集成第三方後端服務。

功能需求測試（DEV、QA、ST、UAT）

跨功能需求測試（安全性、性能等）

部署到生產環境。

低代碼開發流程：

分析、設計、確認、規劃需求

選擇需要的第三方 API

在可視 IDE 中繪製應用程序的工作流程、數據模型和用戶界面。

連接 API——通常使用服務、函數發現。

編寫業務邏輯（可選）。手動代碼添加到前端或者自定義自動生成的 SQL 查詢。

用戶驗收測試。

部署到生產環境。

從步驟上來看，無代碼編程少了幾個步驟。這些步驟都因為大量豐富的內部系統集成，而變得非常簡單。

適用場景

就當前而言，無代碼編程實際上是一種高度的場景預設的模式。因此，它存在一定的適用場景：

模型驅動開發。

快速 UI 構建。

極簡的業務功能。

IT 資源受限。在資源受限的情況下，能快速開發出符合業務需求的應用最重要。

而從流程上來看，對於一部分的應用來說，我們並不能實現無代碼編程——存在一些業務上的不同之處。因此，多數場景之下，只是實現了低代碼編程。

若是想真實的無代碼編程，則需要一些更特定的場景：

設計表格（輸入數據）

創建報告（組織數據）

常規調度和自動化過程（操縱數據）

更多的場景正在探索中。

無代碼編程的挑戰

無代碼編程，除了需要準備好上述的一系列基礎設施，還不可避免地會遇到一系列挑戰。

誰來寫這部分代碼？

客戶端的基礎設施準備。

服務端的服務平台搭建。

統一用戶體驗設計。設計出一系列能便利組合的組件，及對應的模板頁面。與此同時，它們還能適應於不同的風格，即有多樣性的主題支持。

DevOps 流水線設計。低代碼編程，依賴於一系列的自動化工具，以實現構建、調試、部署以及維護，同時還包含應用的測試。

領域語言設計。

自動化測試。如果我們的前端代碼是自動生成的，那麽我們還需要對它們進行測試嗎？這是一個好問題，而如果代碼是自動生成的，那麽測試也應該是自動生成的。畢竟要在平台上，編寫大量的自動化測試，以保證平台的質量。

其中，有一些部分略微複雜一些，我們大概可以探索一下。

誰來寫這部分代碼？

在我們創建這樣一個平台和工具時，我們要考慮的第一個問題是，這個工具是為誰寫的？

沒有編程經驗的人。如業務人員，他/她們對於業務系統有著非常豐富的經驗。

有編程知識，但是沒有經驗的人。

有一定經驗的開發人員。

有豐富經驗的開發人員。對於專業的人來說，自動化就意味著缺少靈活度。甚至與自己編寫相比，他們要花費更多的時間來修複生成的代碼。

顯然，對於相當有經驗的開發人員而言，這個工具並不一定是他們所需要的。

客戶端基礎設施

從我的理解來看，它適合於快速的 MVP 構建，並且生成的代碼還應該方便修改，而不是諸如早期的 DreamWeaver 或者 FrontPage 這樣的工具。

而與此同時，由於面向的開發人員水準不同，我們所需要做的工具也不同：

支持雲構建和調試。

GUI 編程應用。

代碼生成。

設計系統體系構建。組件庫搭建，模板應用創建等。

更難的是，容易讓開發人員能接受代碼生成。

服務端

對於一個低代碼平台而言，它對應的後端應該：

大量可用的現有服務。身份驗證、安全性、推送能力、地圖等等。

快速構建出後端服務。若是有內部 Serverless 或者 FaaS 方案，可以說是再好不過了。

方便與第三方服務集成。

靈活性。支持多語言等。

統一的後端服務 API，對於後端服務來說，我們需要一個通用的範式。所有的 API 應該按照這樣的範式來設計。不過，作為一個 API 的消費方，我們可能沒有這麽大的權力，但是我們可以採用裝飾器模式，即封裝第三方 API 成統一的方式。為此，我們採用的方式，仍然是：

契約。諸如 Swagger UI，它可以直接創建一個簡易可用的服務。

BFF。即我們一一去按我們的需要，去封裝這些第三方應用。

查詢語言。與自己編寫 BFF 相比，更簡單的方式是採用：GraphQL 這樣的後端查詢語言，便捷性更高、模式更加靈活。

在開發前的設計期裡，我們需要首先設計出對應的領域模型。

領域語言設計

低代碼環境使用（圖形）建模語言來指定整個系統、產品的行為。它意味著：

將數據結構、領域模式應用到程序的各個層級中。

將業務規則、決策融入到應用中（層級）。

這也就意味著，我們需要設計一個模型語言。而它對於我們而言，實際上是領域特定語言（DSL）。如下是一個簡單的 DSL 示例，用於描述使用到的組件：

{'style':'','id': 2,'blocks':

[{'content': {'content':'content','title':'hello'},'type':'card'}]

}

除此，我們還需要設計對應的布局 DSL，諸如於：

H:[circle1(circle1.height)] // set aspect-ratio for circle1

HV:[circle2..5(circle1)] // use same width/height for other circles

H:|[circle1]-[circle2]-[circle3]-[circle4]-[circle5]|

V:|~[circle1..5]~| // center all circles vertically

最後，我們還需要將流代碼，轉換為真實的項目代碼。三種類型的 DSL 結合下來，都不是一個輕鬆的工具。

原型設計

寫好現有的組件，通用型接口。如常見的登錄接口，對於使用登錄接口的業務來說，它們隻關心三部分的內容：

成功登錄。

取消登錄。

登錄失敗。對於客戶端而言，可以視為取消登錄。對於服務端來說，則可能是密碼錯誤、用戶名不存在、账號被鎖定等。

對應於以上情景，又有一些通用的邏輯處理：

登錄成功。保存 Token，並返回歷史頁面。

登錄失敗。彈出一個自定義內容的提示框。

這些代碼是相似的。

前端原型

在一些簡單的前端應用裡：

模板。只是在使用這些模板，再為這些模板設置相應的屬性，綁定對應的值。

數據。其過程都只是在各種保存變量的值，並 CRUD 這些變量的路上。為此，我們需要一個數據處理的管道架構設計，用於處理這些值。

函數。事實上，我們的所有函數都只是一些管理函數，隻用於處理這些對應的邏輯。

這些常見的功能都可以做成一些組件，它們對於某些應用來說，代碼相應的重複。

無限加載頁面。只需要綁定上 API，再控制一下元素的顯示與隱藏即可。

表單。定義好資料欄即類型，對應的前後台邏輯都有了。除此，我們還需要為它們自定義好常見的規則，如正則表達式。而一旦表單之間有聯動，那麽這個組件的設計就更加麻煩了。

卡片式元素。

表單和表格展示。

常見圖表。事實上，已經有一系列的圖表工具了，我們只是在它們在基礎上，進行了二次封裝而已——使得它們可以變成領域語言的形式。

高級的響應式布局。與每個應用獨立開發布局不同的是，低代碼平台需要提供一套強大的自定義、響應式布局設計——即要滿足移動端的通用模式，還要滿足桌面版的通用模式。如對於大量數據來說，桌面端使用的是 Pagination，移動端使用的是無限滾動。

後端原型

事實上，對於後端來說，低成本平台意味著，代碼生成及服務生成。而服務本身是有限的，既然是業務上發生了一些變化，後端服務也可能並不會發生變化。

它也意味著：

微服務化。每個後端服務要盡可能的小。

API 規範化。即採用統一的 API 格式，接受統一的權限管理

大量的 API 服務。

快速集成第三方服務方案。集成第三方服務是開發應用不可避免的情況。為了應對這個問題，我們需要做準備好對應的創建服務邏輯，傳入第三方服務所需要的參數，便可以直接生成我們的轉發服務。

那麽，問題來了，既然如此，我們是否能提供一個定製的工具呢？讓每個人可以創建自己的組件流？

答案，顯然是可以的。

概念證明

於是乎，在我最近設計的 PoC （概念證明）裡，採用的是 Anguar 框架。相應的基本思想如下：

使用 Material Design 作為組件庫，使用 CDK 的 Drag 來實現拖拽功能。每個拖拽的組件，稱為 Element（元素），由 ElementDispatcher 由根據數據生成對應的組件。可拖拽的部分由兩部分組成：布局 + 元素。

UI 構建完後，生成對應的 DSL，目前採用的是 JSON。畢竟數據結構是最簡單的領域特定語言。

借由 Angular Schematics 解析這部分的 DSL，來生成相應的項目代碼。

相關開源項目：

拖拽式 Web 建造工具：https://grapesjs.com/

基於 Flow 的編程工具：https://noflojs.org/

DSL 布局生成器：https://github.com/ijzerenhein/autolayout.js/

可視化數據流編輯器：https://github.com/Gregwar/blocks.js

基於 React 的內容生成器：https://github.com/vigetlabs/colonel-kurtz