前端工程化之低代碼體系

本文由團隊成員 蕭凡 撰寫，已受權塗鴉大前端獨家使用，包括但不限於編輯、標註原創等權益。

前言

一千我的的眼中確定有不止一千個哈姆雷特，本文探討的並不只僅侷限可視化搭建，而是提升研發效率的低代碼體系。

下文將圍繞低代碼體系，分享一下對這套體系的理解。若有不一樣的意見，歡迎探討！

什麼是低代碼

定義

一切能經過少寫代碼來完成業務的方式均可以歸入低代碼體系。

低代碼是介於無代碼與全代碼之間的體系，藉助工具、約束、配置生成的通用業務代碼，在此基礎進行少許改動以便快速進行不一樣的定製化業務開發。

對比

無代碼的優點：

1. 使用、配置的過程簡單
2. 無開發經驗的成員（如運營、產品、設計等）便可經過此體系完成功能業務的開發

無代碼的劣勢：

1. 業務模型、邊界單一，沒法進行特殊功能定製
2. 研發介入的時候，因爲要考慮兼容、特殊化定製等問題，致使更新滯後性且耗時嚴重

低代碼的優點：

1. 能夠藉助搭建、配置等手段快速生成基礎業務代碼
2. 業務模型、邊界的範圍擴大，且能夠再基礎代碼上進行二次定製開發
3. 二次定製開發的過程當中能夠進行物料積累，反饋到低代碼體系中，完善流程

低代碼的劣勢：

1. 搭建、配置的過程，須要瞭解必定的開發體系知識，上手成本超過無代碼
2. 業務模型、邊界雖然擴大但依然有必定的範圍限制（如：電商行業、物聯網模型等）

簡單來看，低代碼是在無代碼的基礎上作了必定的容錯與改進，以便開發可以更好地介入，提升整個項目週期的效率。

低代碼的技術意義與商業價值

經過上面的簡單對比分享以後，再繼續在技術與商業上面對低代碼體系來更深層次的探討一下

技術意義

1. 同種類型業務的快速迭代是不用多說的，提升了效率，減小了成本。
2. 可視化的技術能夠將低代碼體系從研發的角色延伸到設計、產品、運營等角色，在項目開發初期的時候對項目就能作出必定的分析與構建
3. 經過低代碼生成的項目，能夠統一進行基礎庫的升級。埋點、檢測等一系列的有規則的統一配置都使用相對應的低代碼生成。
4. 減小人工開發，測試迴歸、問題定位就會更加精準。

商業價值

將技術上的意義所有體如今商業中能夠總結爲下面 3 點：

1. 速度：能夠快讀搭建基礎項目、進行個性化定製
2. 成本：減小中級研發的投入
3. 安全：機器永遠比人安全，產生的問題會更少，且更容易定位

你們可能會感受，爲何減小的是中級研發的，而不是初級。在低代碼體系完成以後其實最艱難的是熟練工，熟練的去開發業務而不是工具的這幫人。初級工能夠藉助這套體系快速成爲熟練工，那麼以前可以熟練開發業務的人員的價值就勢必會減小。要不繼續再往上走，成爲定製體系的人，要不就減小本身的價值以符合企業的成本。

舉一個例子：電動車的出現倒逼不少中小型的自行車公司的破產，可是頂層自行車的車場感覺會小一點，但也沒有好多少。換在開發也是同樣，在大背景的碾壓下，即便頂級作自行車的都很吃力，那麼剩下的就只能轉到電動車上了。

低代碼體系的搭建

這裏的搭建並不只僅侷限於低代碼的搭建工程，而是指的是怎麼樣去搭建一套適合本身當前業務的低代碼體系。

業務 + 物料庫

低代碼的體系完成是必定是貼合當前業務，或者是貼合某一類通用的業務模型。

因此在進行低代碼體系搭建的過程當中，首先必定會積累大量業務模型，進行不斷的訓練。

那麼第一步的產出就是對業務的提煉，從基礎的組件庫上升到物料庫。

這裏將物料庫的組成再放大一點（暫時沒有更好的詞語形容）

物料庫是由基礎組件、業務組件、業務模板、業務框架、基礎代碼區塊、業務代碼區塊等等一系列組成的一個龐大的物料體系。

基本上能夠經過上述的物料碎片快速構建出完成當前業務 70 - 90% 以上的代碼。

當完成上述的要求以後，就能夠考慮下一步的怎麼樣利用工具或者規範來提升效率。

交互 + 效率

低代碼體系的第二步是交互與效率。

1. 從最基礎的 CLi 工具開始着手，搭建符合本身業務的 CLi 工具，經過簡單的交互，便可添加對應的代碼區塊、選擇對應的業務模板
2. 聯合後臺，經過接口產物，直接生成對應的表單、表格模板。
3. 經過 Sketch 解析或者 AI 識圖，產生對應的結構代碼。（Sketch 能夠經過工具解析成樹狀接口，經過添加對應的節點標記，能夠拿到你想要的元數據）

若是你們接觸前端的年限比較早的話，那麼必定聽過或使用過 Dreamweaver 這款前端工具。實時預覽 + 拖拽配置很酷炫，但沒有業務模型約束，也沒有上述物料庫的支持，生成出來的代碼還不如手寫，那麼這款產品只有在 demo 階段仍是有很不錯的效果，但在實際開發中就失去了所具有的優點。

這是一個反面的例子，若是你設計的低代碼體系在實際運用中的效率遠低於直接編程帶來的結果，那麼這個體系必定是失敗的。

產品不必定是差的，可是使用這個產品帶來的結果也不必定是好的。一切流程、工具都是須要緊貼合業務走，才能發揮最大的價值。

從第二點能夠看出，不只僅是有界面交互的過程才被稱爲低代碼。後端能夠經過工具將對應的接口參數抽離、組合，直接生成對應的 CURD 頁面，只要符合必定的規則與樣式，也就是表單、表格的基礎組件具有的狀況下，能夠直接輸出業務頁面甚至是一個簡單的 CURD 項目。低代碼體系的構建不只僅限於可視化搭建這一塊，而是貫穿整個業務研發流程的。

固然可視化搭建工程一直都是最直觀、簡單的低代碼手段，但仍是要強調，拖拽搭建也只是一種手段並非惟一。

可以以最少的人力介入開發的流程、工具均可以歸屬到低代碼體系。

流程設計

大多數低代碼設計是抽象了總體的業務模型經過 JSON 配置，以必定的解析規則來生成具體的代碼。

那麼如圖所示（二次開發帶來的是個性化定製，足夠豐富的物料庫在面對簡單業務的時候甚至能夠省去這一步），配置生成即表明了具備必定的約束。

項目配置大致能夠分爲 2 級：

1. 基礎類型選擇：移動端、PC、跨端、RN、小程序等
2. 業務類型選擇：電商、廣告、大屏、財務等

從選擇項目類型決定最後的組件配置，每種項目類型的選擇帶來的不只僅是基礎組件的渲染更是業務組件的選擇。

具體的 JSON 配置與可視化搭建相關的內容，有不少的博客都介紹到，後續有部分的博文推薦，你們能夠看下。

總結

可能部分同窗對低代碼有些誤會就是低代碼平臺的受衆必定是非程序員。這個先入爲主的狀況感受坑了很多的研究低代碼搭建的同窗。

其實應該是低代碼平臺產出的產品的受衆是非程序員，而使用低代碼平臺的必定是程序員或者懂一些編程思想的人。

若是低代碼體系是貼合目前的業務狀況下，經過可視化搭建這種簡易交互能將部分的業務能力轉嫁到對應的運營、產品、設計身上。

將部分轉嫁出去的業務封裝的足夠簡即是能夠下降部分研發時間，可是這一部分對他們來講是無代碼接觸。不能將低代碼的編程思想帶入太多而形成額外的心智負擔。（無代碼想要達到低代碼的結果是配置過程極其複雜。）

這是爲何前文一直在強調的要有業務模型與邊界，當脫離了業務模型與邊界以後，你會發現可視化搭建的心智成本帶來的反作用會遠超單純的工具組合開發。

寫在最後

會開發工具的研發不必定是好研發但不會開發業務的研發必定不是好研發。

以技術輔助業務，以業務反饋技術。

發現寫完上面的東西，發現最後淘汰的就是我這種切圖仔，寶寶瞬間就不開心了。

推薦博文

關於低代碼( low-code )這回事

如何設計實現 PC 站點搭建系統 - Schema

淺談 low code