完美世界手游官网隐藏任务 www.gytoi.icu

中臺之后,便是無代碼編程。

規?;淖櫓?,經常要面臨這樣的挑戰:每個應用的基礎設施是相同的,部分的代碼也是相同的,甚至于它們可能只是數據模型不同而已。結果卻導致了,他/她們要一次又一次地重新編寫一個應用。

對于一個新的應用而言,它需要對接大量的三方(非自己團隊)服務。服務之間的不斷變化 ,導致了對應的使用方也需要發生變化。不斷變化的業務,導致了前臺的設計不斷變化。為了應對快速談的的前臺服務,后臺便誕生了中臺,以提供快速的響應能力。而隨著中臺進一步沉淀,從某種形式上趨于穩定,而前臺仍然需要快速地響應能力。

于是乎,作為一個前端開發人員,我們不斷提煉和復用代碼,想著的模式在上一篇文章 減少代碼量的 7~8 種方式 中提到了:

  • 腳手架
  • 組件庫
  • 模式庫
  • 模板和模板應用

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

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

什么是無代碼編程?

無代碼/低代碼是一種創建應用的方法,它可以讓開發人員使用最少的編碼知識,來快速開發應用程序。它可以在圖形界面中,使用可視化建模的方式,來組裝和配置應用程序??⑷嗽笨梢災苯猶械幕〖芄?,只關注于使用代碼來實現業務邏輯。

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

  1. 框架本身處理了復雜性。畢竟 “復雜度同力一樣不會消失,也不會憑空產生,它總是從一個物體轉移到另一個物體或一種形式轉為另一種形式?!?/strong>
  2. 代碼生成減少了工作量。大量的復制、粘貼需要更多的時間。

流程

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

圖1:無代碼編程

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

  • 用于構建 UI 的編輯器——一種在線的拖拽式 UI 設計和頁面構建工具
  • 用于編寫業務邏輯的流編輯器——通過流編程的方式來編寫業務代碼(多數是對于數據的處理)

UI 編程器。為了設計出我們的 UI 構建器,我們需要準備好一系列的基礎設施:

  • UI 編程器。用于拖拽式設計 UI。
  • 空白腳手架。一個帶有完整的應用生命周期的項目,但是它是一個空白的項目——用于我們在構建 UI 的過程中,隨時隨地的添加組件和代碼。
  • 設計系統。我們需要一個完整的組件庫,大量的頁面模板,以及一定數量的模板應用,減少相應的開發工具量。
  • 代碼片段集。它將設計系統中的組件庫進一步實例化成代碼段,在完成編輯后通過 CLI 來動態編輯代碼。
  • DSL(領域特定語言,可?。?。中間生成物,用于隔離框架與設計。

流編程器。隨后,為了在

  • 流編程器。用于拖拽式、輸入編寫業務代碼。
  • 后端服務。如果不能提供現成的后端服務,則需要擁有一個標準的 API 規范,以及相應的 mock server。
  • 模式庫。包含相應的業務處理代碼,如通用的登錄、數據獲取、UI 交互等。
  • DSL(領域特定語言,可?。?。同上

當然了,我們還需要能實時預覽構建出來的應用。隨后,我們執行了構建,而后構建出了一個半成品應用??⑷嗽敝恍枰謁幕∩峽⒂τ眉純?。而在開發人員開發的過程中,我們可以設計一系列的工具,來幫助開發人員更快速地構建應用。

  • 編輯器插件。包含設計系統、模式庫等的自動完成代碼,以及組織內部常用的代碼庫。
  • 調試工具。對于混合類型的應用而言,我們還需要一個開發工具來快速構建應用。

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

  • 拖放式界面。又或者是可視化模型——基于節點和箭頭
  • 基于視覺的設計。
  • 可擴展的設計。如對于插件、插件商店,社區等一系列的支持。
  • 跨平臺功能。支持 PC Web 應用開發,支持移動應用構架等。
  • 強大的部署后。即平臺包含著整個應用的生命周期。
  • 擁有豐富的集成支持??梢運嬉獾惱業叫枰淖榧?,以及對應的后臺服務。
  • 配置化。它也意味著大量的自定義配置。
  • 自制的領域特定語言(可?。?。用于構建時優化。

優缺點

相應的,它具有以下的一些特點:

  1. 高效。不用多說,節省時間和開發成本。
  2. 有限的 Bug,安全性。
  3. 低成本。其所需的預算非常有限。
  4. 易用(取決于設計)。
  5. 開發速度更快。
  6. 開發過程中的 AI 。
  7. 維護成本低。

對應的相應的缺點有:

  1. 仍然需要編程技能。
  2. 受限的自定義能力。
  3. 可擴展性成了新的問題。
  4. 集成受限。

就當前而言,低代碼開發平臺通常分為兩大類:

  • 對于外部:制作簡單的產品,如網絡移動應用程序
  • 對于內部:為您的團隊或企業創建業務應用程序

諸如只使用 CRUD、表單、驗證、簡單聚合、分頁等簡易的服務。最常見的例子就是表單構建了,諸如金數據這樣的應用,便是可以直接通過拖拽元素來生成,相應的開源實現有 jQuery Form Builder。對于開發人員來說,我們只需要定義好數據模型,再通過拖拽來決定元素的位置即可。從這種角度來看,只要能使用 Serverless 構建的應用和服務,都可以直接使用低代碼開發模式。

開發流程對比

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

  1. 分析、設計、確認、規劃需求
  2. 設計系統架構
  3. 搭建前后端項目。選擇技術棧、從零開始搭建或者從腳手架中創建。
  4. 搭建持續集成。
  5. 創建線框圖和高保真原型。
  6. 設計數據模型,定義前后端契約,即 API URI、方法、字段等。
  7. 前后端實現業務邏輯。
  8. 前端實現 UI 頁面。
  9. 集成第三方后端服務。
  10. 功能需求測試(DEV、QA、ST、UAT)
  11. 跨功能需求測試(安全性、性能等)
  12. 部署到生產環境。

而,低代碼開發流程:

  1. 分析、設計、確認、規劃需求
  2. 選擇需要的第三方 API
  3. 在可視 IDE 中繪制應用程序的工作流程、數據模型和用戶界面。
  4. 連接 API——通常使用服務、函數發現。
  5. 編寫業務邏輯(可?。?。手動代碼添加到前端或者自定義自動生成的 SQL 查詢。
  6. 用戶驗收測試。
  7. 部署到生產環境。

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

適用場景

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

  • 模型驅動開發。
  • 快速 UI 構建。
  • 極簡的業務功能。使用這樣的工具,也意味著,我們對于交互和可
  • IT 資源受限。在資源受限的情況下,能快速開發出符合業務需求的應用最重要。

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

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

  • 設計表格(輸入數據)
  • 創建報告(組織數據)
  • 常規調度和自動化過程(操縱數據)

更多的場景正在探索中。

無代碼編程的挑戰

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

  • 誰來寫這部分代碼?
  • 客戶端的基礎設施準備。
  • 服務端的服務平臺搭建。
  • 統一用戶體驗設計。設計出一系列能便利組合的組件,及對應的模板頁面。與此同時,它們還能適應于不同的風格,即有多樣性的主題支持。
  • DevOps 流水線設計。低代碼編程,依賴于一系列的自動化工具,以實現構建、調試、部署以及維護,同時還包含應用的測試。
  • 領域語言設計。
  • 自動化測試。如果我們的前端代碼是自動生成的,那么我們還需要對它們進行測試嗎?這是一個好問題,而如果代碼是自動生成的,那么測試也應該是自動生成的。畢竟要在平臺上,編寫大量的自動化測試,以保證平臺的質量。

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

誰來寫這部分代碼?

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

  • 沒有編程經驗的人。如業務人員,他/她們對于業務系統有著非常豐富的經驗。這也意味著,我們
  • 有編程知識,但是沒有經驗的人。
  • 有一定經驗的開發人員。
  • 有豐富經驗的開發人員。對于專業的人來說,自動化就意味著缺少靈活度。甚至與自己編寫相比,他/她們要花費更多的時間來修復生成的代碼。

顯然,對于相當有經驗的開發人員而言,這個工具并不一定是他/她們所需要的。

客戶端基礎設施

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

而與此同時,由于面向的開發人員水平不同,我們所需要做的工具也不同:

  1. 支持云構建和調試。
  2. GUI 編程應用。
  3. 代碼生成。
  4. 設計系統體系構建。組件庫搭建,模板應用創建等。

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

服務端

對于一個低代碼平臺而言,它對應的后端應該:

  1. 大量可用地現有服務。身份驗證、安全性、推送能力、地圖等等
  2. 快速構建出后端服務。若是有內部 Serverless 或者 FaaS 方案,可以說是再好不過了。
  3. 方便與第三方服務集成。
  4. 靈活性。支持多語言等。

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

  • 契約。諸如 Swagger UI,它可以直接創建一個簡易可用的服務。
  • BFF。即我們一一去按我們的需要,去封裝這些第三方應用。
  • 查詢語言。與自己編寫 BFF 相比,更簡單的方式是采用:GraphQL 這樣的后端查詢語言,便捷性更高、模式更加靈活。

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

領域語言設計

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

  1. 將數據結構、領域模式應用到程序的各個層級中。
  2. 將業務規則、決策融入到應用中(層級)。

這也就意味著,我們需要設計一個模型語言。而它對于我們而言,實際上是領域特定語言(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 結合下來,都不是一個輕松的工具。

原型設計

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

  1. 成功登錄。
  2. 取消登錄。
  3. 登錄失敗。對于客戶端而言,可以視為取消登錄。對于服務端來說,則可能是密碼錯誤、用戶名不存在、賬號被鎖定等。

對應于以上情景,又有一些通用的邏輯處理:

  1. 登錄成功。保存 Token,并返回歷史頁面。
  2. 登錄失敗。彈出一個自定義內容的提示框。

這些代碼是相似的。

前端原型

在一些簡單的前端應用里:

  • 模板。只是在使用這些模板,再為這些模板設置相應的屬性,綁定對應的值。
  • 數據。其過程都只是在各種保存變量的值,并 CRUD 這些變量的路上。為此,我們需要一個數據處理的管道架構設計,用于處理這些值。
  • 函數。事實上,我們的所有函數都只是一些管理函數,只用于處理這些對應的邏輯。

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

  • 無限加載頁面。只需要綁定上 API,再控制一下元素的顯示與隱藏即可。
  • 表單。定義好字段即類型,對應的前后臺邏輯都有了。除此,我們還需要為它們自定義好常見的規則,如正則表達式。而一旦表單之間有聯動,那么這個組件的設計就更加麻煩了。
  • 卡片式元素。
  • 表單和表格展示。
  • 常見圖表。事實上,已經有一系列的圖表工具了,我們只是在它們在基礎上,進行了二次封裝而已——使得它們可以變成領域語言的形式。
  • 高級的響應式布局。與每個應用獨立開發布局不同的是,低代碼平臺需要提供一套強大的自定義、響應式布局設計——即要滿足移動端的通用模式,還要滿足桌面版的通用模式。如對于大量數據來說,桌面端使用的是 Pagination,移動端使用的是無限滾動。

后端原型

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

它也意味著:

  • 微服務化。每個后端服務要盡可能的小。
  • API 規范化。即采用統一的 API 格式,接受統一的權限管理
  • 大量的 API 服務。
  • 快速集成第三方服務方案。集成第三方服務是開發應用不可避免的情況。為了應對這個問題,我們需要做準備好對應的創建服務邏輯,傳入第三方服務所需要的參數,便可以直接生成我們的轉發服務。

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

答案,顯然是可以的。

概念證明

于是乎,在我最近設計的 PoC (概念證明)里,采用的是 Anguar 框架。相應的基本思想如下:

  1. 使用 Material Design 作為組件庫,使用 CDK 的 Drag 來實現拖拽功能。每個拖拽的組件,稱為 element(元素),由 ElementDispatcher 由根據數據生成對應的組件??賞獻У牟糠鐘閃講糠腫槌桑?strong>布局 + 元素。
  2. UI 構建完后,生成對應的 DSL,目前采用的是 JSON。畢竟數據結構是最簡單的領域特定語言。
  3. 借由 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

參考資料:

  1. https://www.process.st/low-code/
  2. https://medium.com/@stefan.dreverman/decisions-to-take-for-your-low-code-architecture-c0768b606f
  3. https://medium.com/@stefan.dreverman/analyzing-coinmarketcap-data-with-neo4j-4930ba0068e1
  4. https://www.outsystems.com/blog/what-is-low-code.html
  5. https://medium.com/@stefan.dreverman/starting-a-low-code-application-architecture-13170fcd6fc7
  6. https://www.quora.com/What-is-low-code
余下全文(1/3)

本文最初發表在www.phodal.com,文章內容屬作者個人觀點,不代表本站立場。

分享這篇文章:

請關注我們:

發表評論

電子郵件地址不會被公開。 必填項已用*標注