【🧪 前端實驗室】2020 前端可視化搭建小報告 - 01 - 背景調研

本次小報告由於篇幅的考慮,分紅了三塊:01 背景調研 - 02 鏈路、架構和難點 - 03 業內成果陳列,此篇是第一部分,會從四個維度(What、Who、Why、How)來介紹前端可視化搭建。前端

👨🏽‍💻 筆者兩三句: 我本人是由於最近有一個契機,想在可視化搭建這塊深挖一下,作一份小報告。雖然我本身業務裏沒有作過這樣的事,但不妨礙我站在一個研究者的角度,爲你們整理一些資料。git

這份報告先後大概總共花了兩三天的時間,看完這三篇小報告,雖然不會讓你立馬能完成一個可視化搭建系統,但至少能讓你能領略一下可視化搭建的進展和麪貌。github

可視化搭建涵蓋的內容是很是多的,越是深刻越能發現每個細點都是一個至關的複雜的研究命題,筆者本身也在不斷地完善這份小研究。web

0. 一些前置的知識

常見的可複用代碼片斷的粒度

從可複用代碼片斷的顆粒度來看,咱們一般接觸到的概念以下:後端

基礎組件業務組件(區塊\微件)模板(頁面主體)api

  • 基礎組件,如各大組件庫所完成的細粒度組件,Button \ Input \ Form等。
  • 業務組件,針對不一樣項目的業務場景,有一些場景可複用但不足以泛用的顆粒度較大的組件,咱們將其封裝爲業務組件。
  • 模板,顆粒度最大的組件,如活動頁、表單頁面模板、後臺管理頁模板、數據可視化模板,這些都是通過大量業務實踐,證明可複用的頁面主體架構

飛冰給出了一張更詳細的關於粒度的參考圖,其中的業務組件也能夠稱爲 widgets和基礎組件(components)相區分:瀏覽器

飛冰 - 粒度參考圖

前二者咱們能夠經過組件庫和業務微件庫,造成通用的代碼片斷倉庫,而模板咱們也能夠藉由 GUI(圖形用戶界面,也可稱爲可視化管理平臺),管理咱們在業務中遇到的經常使用模板。安全

不一樣粒度的代碼塊

模板搭建平臺中,Ant Design Landing 應該是比較典型且有知名度的解決方案。markdown

它是一個面向產品首頁的快速搭建解決方案,包含了豐富的模板和模板裏對應的模塊,同時提供了一個在線的編輯器。架構

Ant Design Landing

這裏還有一張我的以爲很不錯的由政採雲團隊完成的模板可視化管理平臺的截圖,以下

政採雲 - 模板可視化管理平臺

1. What 可視化搭建是什麼?

可視化搭建 是指在圖形界面上,經過一系列的編輯操做,在極短期內便能完成一個複雜的頁面併發布上線。

可視化搭建 是一個工具,是一個腳手架,也是一個業務加速器和創意製做平臺。

可視化搭建 是高效利用組件的前端上層建築,做爲一個龐大的可視化前端應用, 它創建在大量的前端基建(如代碼規範、腳手架、組件庫、框架等)之上。

雲鳳蝶 - 可視化搭建管道圖

下圖描述了可視化搭建在技術開發層面的具體位置,也能夠做爲可視化搭建的架構示例。

政採雲 - 可視化搭建所處的位置

2. Who 可視化搭建面向誰?

面向誰是一個很關鍵的問題:

  • 若是面向的是營銷頁面或者產品主頁的搭建,使用者一般是非開發者,總體的可視化解決方案就會更偏近 no-code,也就是咱們所說的的零代碼。
  • 若是面向的是中後臺頁面搭建,使用者是開發者,總體的可視化解決方案就會更偏近 low-code,也就是低代碼。

雖然最終的目標是實現全部頁面的零代碼化,可是對於技術邏輯和業務邏輯比較複雜的場景,仍是須要作一些定製的。

iceluna - 可視化搭建面向誰?

3. Why 爲何作可視化搭建?

隨公司業務不斷髮展,營銷活動、廣告、頁面改版等需求日益倍增,靠純人工擼代碼已經沒法跟上需求增加速度。加班?招人?顯得不夠明智,也不夠前端,提效也就成爲了關鍵。如何提效?從何入手?那不得不提的就是前端提效神器 —— 可視化搭建系統。

當組織團隊達到必定的開發規模時,頁面可視化搭建是一個減小冗復開發、釋放生產力的最有效方案。

低代碼能讓不懂代碼的業務人員成爲所謂的平民開發者(Citizen Developer),彌補日益擴大的專業人才缺口,同時促成業務與技術深度協做的終極敏捷形態(BizDevOps)

對於傳統開發者而言,在實際的業務開發過程當中,既要關注業務複雜度,又要關注技術複雜度,而低代碼平臺(可視化搭建)就是爲了儘量地屏蔽掉技術細節,轉移出大部分的技術複雜度,從而減輕業務線開發的負擔。

阿里雲原生 - 低代碼化平臺的定位

總結一下前端可視化搭建要實現的目標:

  1. 實現業務快速交付
  2. 下降業務開發成本

而對於前端可視化搭建的願景,初步的理解能夠以下:

調動全部非前端開發人力,釋放前端開發的工做量,讓人人都能參與到頁面的搭建中,提高項目的交付效率。

固然可視化搭建的將來遠不止於此,好比ServerlessDevOps 全鏈路的打通結合 AI 的應用等。

爲何會選擇不使用lowcode

除此以外,還有一些針對用戶的「爲何」的問題須要討論:若是開發或者非開發不想用低代碼平臺,是會由於什麼?

  1. 低代碼平臺的能力受限

    按照目前的低代碼平臺產品來看,你們的應用場景和成熟度大不相同,具體的價值仍是得結合業務場景和使用頻次來考量這件事情。若是隻是應用模板完成業務的低代碼平臺,它自己就不須要特別複雜的能力,能快速產出可上線的宣傳頁面就行。若是是涉及大量業務邏輯的中後端平臺,低代碼也能幫助咱們減小許多重複的工做,讓開發者專一於業務邏輯。

  2. 低代碼平臺就像是一個玩具,我不瞭解它的內部邏輯,也沒有辦法相信它產出的質量

    瀏覽器剛出來的時候,你們也不會說主動了解它的內核運行機制,因此關鍵仍是,能不能用起來用得爽用得放心,這須要咱們持續地創建數據收集和分析。除此以外,關於安全合規以及漏洞風險的考慮,也是在低代碼平臺開發過程當中須要考慮的,咱們能夠多讓你們用起來,調動用戶幫助咱們尋找其中的漏洞,並創建安全機制,防止有人惡意攻擊。

  3. 低代碼平臺維護起來方便嗎?

    成熟的低代碼平臺能提供規範的接口、完整的構建發佈鏈、質量保障體系以及簡便明瞭的操做,若是連產品經理都能隨時維護,做爲一個開發者還有什麼須要擔憂的。

4. How 怎麼作可視化搭建?

基礎思路: 先調用一個模板做爲基礎骨架,而後經過控制組件的屬性,經過少許的代碼調整,使得大體的頁面效果可以與業務高保真圖保持一致,最後接入數據接口,進入構建、測試和發佈流程。

阿里雲原生技術團隊列出了低代碼平臺須要實現的三個核心能力:

低代碼平臺的三個核心能力

爲了達成這樣的能力維度或者實現這樣的核心能力,其實須要不少層面的支撐,如工具鏈物料平臺工程套件接口編排等,下面展現了一張阿里媽媽的產品家族,你們能夠略窺一二。

阿里媽媽 - 產品家族

關於具體的架構層和一些可視化搭建領域的技術難點,移至第二篇研究報告中展開介紹。

若是你不想考慮那麼多架構層的問題,只想快速地完成一個可視化搭建的雛形,松果出行工程師的這篇技術文章應該能幫到你

# 參考文章

這裏不少資料,來源於本人蔘與的早早聊大會的講師 PPT 材料,在這其中我作了一些篩選和整合,加入了本身的分析和製做的圖表,也歡迎各位關注這個乾貨滿滿的會議。

再列舉一些其餘參考的公開文章或者網站:

  1. 《前端工程實踐之可視化搭建系統(一)》
  2. 《MPM 賣場可視化搭建系統 — 要素設計》
  3. Github - awesome-lowcode
  4. 《阿里雲原生 - 什麼是低代碼(Low-Code)?》
  5. Wiki - 低代碼開發平臺
  6. 《騰訊 - AlloyTeam - 頁面可視化搭建工具技術要點》
  7. 《這,就是飛冰物料》
相關文章
相關標籤/搜索