從前端智能化看「低代碼/無代碼」

簡介： 什麼是低代碼/無代碼開發？業界對於低代碼/無代碼開發是否存在其餘不一樣的理解？低代碼開發和無代碼開發之間的區別是什麼？

做者 | 甄子
來源 | 阿里技術公衆號

一 概念
1 什麼是低代碼/無代碼開發？業界對於低代碼/無代碼開發是否存在其餘不一樣的理解？
行業裏流行觀點，低代碼是更加易用的搭建系統，無代碼是圖形化和可視化編程。這種觀點把低代碼和無代碼開發分別置於 UI 和邏輯兩個環節，以工具屬性定義搭建和可視化編程要解決的問題。另外一種觀點則是把低代碼/無代碼看做一個方法的兩個階段，就像對自動駕駛的 L0 ~ L5 共 6 個不一樣階段同樣，把我以前在《人機協同的編程方式》[1] 一文提出的人機協同編程的概念，劃分爲低代碼/無代碼兩個階段。較之第一種我更加認同第二種觀點，不只由於是我提出的，更由於第二種觀點是以軟件工程的統一視角定義、分析和解決問題，而第一種觀點只是局部和過程的優化而非顛覆性創新。

今天「人機協同的編程方式」把軟件工程從拼裝 UI 和編寫業務邏輯裏解放出來，逐步向業務能力、基礎能力、底層能力等高技術含量工做過渡。更多內容參考《前端智能化：思惟轉變之路》[2]。

2 低代碼開發和無代碼開發之間的區別是什麼？
接着上述所答，既然低代碼和無代碼屬於「人機協同編程」的兩個階段，低代碼就是階段1、無代碼則是階段二，分別對應「人機協做」和「人機協同」。協做和協同最大的區別就是：心有靈犀。不論低代碼仍是無代碼，均有服務的對象：用戶。不論用戶是程序員仍是非編程人員，均有統一目標：生成代碼。不論源碼開發、低代碼仍是無代碼，都是在用不一樣的方式描述程序，有代碼、圖形、DSL……等。「人機協做」的階段，這些描述有各類限制、約束，應用的業務場景亦狹窄。「人機協同」的階段，則限制、約束減小，應用的業務場景亦寬廣。「心有靈犀」就是指：經過 AI 對描述進行學習和理解，從而減小限制和約束，適應更多業務場景。所以，傳統低代碼/無代碼和「人機協同編程」生成代碼相比，最大的不一樣就是有心和無意，機器有心而平臺無意。

二 背景
1 低代碼/無代碼開發與軟件工程領域的一些經典思想、方法和技術，例如軟件複用與構件組裝、軟件產品線、DSL（領域特定語言）、可視化快速開發工具、可定製工做流，以及此前業界流行的中臺等概念，之間是什麼關係？
從庫、框架、腳手架開始，軟件工程就踏上了追求效率的道路。在這個道路之上，低代碼、無代碼的開發方式算是宏願。複用、組件化和模塊化、DSL、可視化、流程編排……都是在達成宏願過程當中的嘗試，要麼在不一樣環節、要麼以不一樣方式，但都還在軟件工程領域內思考。中臺概念更可能是在業務視角下提出的，軟件工程和技術領域內相似的概念更可能是叫：平臺。不論中臺仍是平臺，就不只是在過程當中的嘗試，而是總體和系統的創新嘗試。我提出前端智能化的「人機協同編程」應該同屬於軟件工程和技術領域，在相似中臺的業務領域我提出「需求暨生產」的全新業務研發模式，則屬於業務領域。這些概念之間無非：左右、上下、新舊關係而已。

2 此外，低代碼/無代碼開發與DevOps、雲計算與雲原生架構之間又是什麼樣的關係？
DevOps、雲計算……都屬於基礎技術，基礎技術的變化勢必帶來上層應用層技術變化。沒有云計算的容器化、彈性縮擴容，作分佈式系統是很困難的，尤爲在 CI/CD、部署、運維、監控、調優……等環節更甚，什麼南北分佈、異地多活、平行擴展、高可用……都須要去關注。可是，雲計算和DevOps等基礎技術的發展，內化並自動化解決了上述問題，大大下降了關注和使用成本，這就是心有靈犀，在這樣的基礎技術之上構建應用層技術，限制少、約束小還能適應各類複雜場景。

三 思想方法
1 支撐低代碼/無代碼開發的核心技術是什麼？
我認爲低代碼/無代碼開發的核心技術，過去是「複用」，今天是 AI 驅動的「人機協同編程」。過去的低代碼/無代碼開發多圍繞着提高研發效能入手，今天 AI 驅動的「人機協同編程」則是圍繞着提高交付效率入手。所以，低代碼/無代碼開發以「人機協同編程」爲主要實現手段的話，AI 是其核心技術。

2 低代碼/無代碼開發的火熱是軟件開發技術上的重要變革和突破，仍是經典軟件工程思想、方法和技術隨着技術和業務積累的不斷髮展而煥發出的新生機？
計算機最初只在少數人掌握，現在，幾乎人人手持一臺微型計算機：智慧手機。當初爲程序員和所謂「技術人員」的專利，而今，幾乎人人都會操做和使用計算機。然而，人們對計算機的操做是間接的，須要有專業的人士和企業提早編寫軟件，人們經過軟件使用計算機的各類功能。隨着計算機算力和功能的不斷髮展，隨着社會的數字化和信息化，今天的人們愈來愈難以被提早定製好的軟件所知足。低代碼/無代碼開發則賦予人們創造軟件的能力，進而幫助人們低成本、即時、高效的直接生產符合本身需求的軟件，進而操做衆多複雜的電子設備和數字世界創建聯結。我認爲，這是不可逆的趨勢，也是低代碼/無代碼開發的大方向。

四 現狀進展
1 低代碼/無代碼開發已經發展到什麼程度？

imgcook

2w 多用戶、6w 多模塊、 0 前端參與研發的雙十一等大促營銷活動、70% 阿里前端在使用
79.26% 無人工參與的線上代碼可用率、90.9% 的還原度、Icon 識別準確率 83%、組件識別 85%、佈局還原度 92.1%、佈局人工修改機率 75%
研發效率提高 68%
uicook

營銷活動和大促場景 ui 智能生成比例超過 90%
平常頻道導購業務 ui 智能生成覆蓋核心業務
純 ui 智能化和個性化帶來的業務價值提高超過 8%
bizcook

初步完成基於 NLP 的需求標註和理解系統
初步完成基於 NLP 的服務註冊和理解系統
初步完成基於 NLP 的膠水層業務邏輯代碼生成能力
reviewcook

針對資損防控自動化掃描、CV 和 AI 自動化識別資損風險和輿情問題
和測試同窗共建的 UI 自動化測試、數據渲染和 Mock 驅動的業務自動化驗證
和工程團隊共建的 AI Codereview 基於對代碼的分析和理解，結合線上 Runtime 的識別和分析，自動化發現問題、定位問題，提高 Codereview 的效率和質量
datacook

社區化運營開源項目，合併 Denfo.js 同其做者共同設立 Datacook 項目，全鏈路、端到端解決 AI 領域數據採集、存儲、處理問題，尤爲在海量數據、數據集組織、數據質量評估等深度學習和機器學習領域的能力比肩 HDF五、Pandas……等 Python 專業 LIbrary
Google Tensorflow.js 團隊合做開發維護 TFData library ，做爲 Datacook 的核心技術和基礎，共同構建數據集生態和數據集易用性
pipcook

開源了 pipcook[3] 純前端機器學習框架
利用 Boa 打通 Python 技術生態，原生支持 import Python 流行的包和庫，原生支持 Python 的數據類型和數據結構，方便跨語言共享數據和調用 API
利用 Pipcook Cloud 打通流行的雲計算平臺，幫助前端智能化實現 CDML，造成數據和算法工程閉環，幫助開發者打造工業級可用的服務和在線、離線算法能力
2 有哪些成熟的低代碼/無代碼開發平臺？

3 低代碼/無代碼開發可以在多大程度上改變當前的軟件開發方式？
隨着計算機算力和功能的不斷髮展，隨着社會的數字化和信息化，今天的人們愈來愈難以被提早定製好的軟件所知足。低代碼/無代碼開發則賦予人們創造軟件的能力，進而幫助人們低成本、即時、高效的直接生產符合本身需求的軟件，進而操做衆多複雜的電子設備和數字世界創建聯結。我認爲，這是不可逆的趨勢，也是低代碼/無代碼開發的大方向。最終，軟件開發勢必從專業程序員手裏轉向普羅大衆，成爲今天操做計算機同樣的基本生存技能之一。所以，軟件開發方式將帶來本質變化，從完整的交付轉向局部交付、從業務總體交付轉向業務能力交付……

五 展望將來
1 低代碼/無代碼開發將來發展的方向是什麼？
要我說，低代碼/無代碼開發將來發展的方向必定是：AI 驅動的「人機協同編程」，將完整開發一個軟件變成提供局部的軟件功能，相似 Apple 的「捷徑」同樣，由用戶決定這些局部軟件功能如何組裝成適合用戶的軟件並交付最終用戶。AI 驅動提供兩個方面的價值：

下降開發成本

以往開發軟件的時候，要有 PRD、交互稿、設計稿、設計文檔……等一系列需求規格說明，而後，根據這些需求規格利用技術和工程手段進行實現。然而，低代碼/無代碼開發交付的是局部功能和半成品，會被沒法枚舉的目的和環境所使用，既然沒法枚舉，就不能用 Swith……Case 的方式編寫代碼，不然會累死。

AI 的特色就是基於特徵和環境進行預測，預測的基礎是對模式和本質的理解。就像 AI 識別一隻貓，無論這個貓在什麼環境、什麼光照條件下，也無論這隻貓是什麼品種，AI 都可以以超過人類的準確度識別。試想，做爲一個程序員用程序判斷一隻貓的開發成本何其高？

下降使用成本

今天的搭建體系，本質上是把編程過程用搭建的思想重構了一遍，工做的內容並無發生變化，成本從程序員轉嫁到運營、產品、設計師的身上。這仍是其次，今天的搭建平臺都是技術視角出發，充斥着運營、產品、設計等非技術人員一臉懵逼的概念，花在答疑解惑和教他們如何在頁面上定製一個搜索框的時間，比本身和他們溝通後源碼實現的時間還要長，並且常常在擼代碼的時候被打斷……

基於 AI 的「人機協同編程」不須要透出任何技術概念，運營、產品、設計……等非技術人員也不改變其工做習慣，都用本身熟悉的工具和本身熟悉的概念描述本身的需求，AI 負責對這些需求進行識別和理解，再轉換成編程和技術工程領域的概念，進而生成代碼並交付，從而大幅度下降使用成本。

舉個例子：若是你英文寫做能力很差，你拿着朗道詞典一邊翻譯一邊拼湊單詞寫出來的英文文章質量高呢？仍是用中文把文章寫好，再使用 Google 翻譯整篇轉換成英文的文章質量高？你本身試試就知道了。究其緣由，你在本身熟悉的語言和概念領域內，纔可以把本身的意思表達清楚。

2 圍繞低代碼/無代碼開發存在哪些技術難題須要學術界和工業界共同探索？
最初在 D2 上提出並分享「前端智能化」這個概念的時候，我就提出：識別、理解、表達 這個核心過程。我始終認爲，達成 AI 驅動的「人機協同編程」關鍵路徑就是：識別、理解、表達。所以，圍繞 AI 識別、 AI 理解、 AI 表達咱們和國內外知名大學展開了普遍的合做。

識別

需求的識別：經過 NLP 、知識圖譜、圖神經網絡、結構化機器學習……等 AI 技術，識別用戶需求、產品需求、設計需求、運營需求、營銷需求、研發需求、工程需求……等，識別出其中的概念和概念之間的關係
設計稿的識別：經過 CV、GAN、對象識別、語義分割……等 AI 技術，識別設計稿中的元素、元素之間的關係、設計語言、設計系統、設計意圖
UI 的識別：經過用戶用腳投票的結果進行迴歸，後驗的分析識別出 UI 對用戶行爲的影響程度、影響效果、影響頻率、影響時間……等，並識別出 UI 的可變性和這些用戶行爲影響之間的關係
計算機程序的識別：經過對代碼、AST ……等 Raw Data 分析，藉助 NLP 技術識別計算機程序中，語言的表達能力、語言的結構、語言中的邏輯、語言和外部系統經過 API 的交互等
日誌和數據的識別：經過對日誌和數據進行 NLP、迴歸、統計分析等方式，識別出程序的可用性、性能、易用性等指標狀況，並識別出影響這些指標的日誌和數據出自哪裏，找出其間的關係
理解

橫向跨領域的理解：對識別出的概念進行降維，從而在底層更抽象的維度上找出不一樣領域之間概念的映射關係，從而實現用不一樣領域的概念進行類比，進而在某領域內理解其它領域的概念
縱向跨層次的理解：利用機器學習和深度學習的 AI 算法能力，放寬不一樣層次間概念的組成關係，對低層次概念實現跨層次的理解，進而造成更加豐富的技術、業務能力供給和使用機會
常識、通識的理解：以常識、通識構建的知識圖譜爲基礎，將 AI 所面對的開放性問題領域化，將領域內的常識和通識當作理解的基礎，不是臆測和猜測，而是實實在在構建在理論基礎上的理解
表達

個性化：藉助大數據和算法實現用戶和軟件功能間的匹配，利用 AI 的生成能力下降千人前面的研發成本，從而真正實現個性化的軟件服務能力，把軟件即服務推向極致
共情：利用端智能在用戶側部署算法模型，既能夠解決用戶隱私保護的問題，又能夠對用戶不斷變化的情緒、訴求、場景及時學習並及時作出響應，從而讓軟件從程序功能的角度急用戶之所急、想用戶之所想，與用戶共情、讓用戶共鳴。舉個例子：我用 iPhone 在進入地鐵站的時候，由於如今要檢查健康碼，每次進入地鐵站 iOS 都會給我推薦支付寶快捷方式，我不用本身去尋找支付寶打開展現健康碼，這就讓我感受 iOS 很智能、很貼心，這就是共情。
六 後記
從提出前端智能化這個概念到如今已歷三年，最初，保持着「讓前端跟上 AI 發展的浪潮」的初心上路，到「解決一線研發問題」發佈[4]，再到「給前端靠譜的機器學習框架」開源[3] ，這一路走來，幾乎日日夜不能寐。真正想從本質上顛覆如今的編程模式和研發模式談何容易？這個過程當中，咱們從一羣純前端變成前端和 AI 的跨界程序員，開發方式從寫代碼到機器生成，周圍的人從做壁上觀到積極參與，正所謂：念念不忘，必有迴響。低代碼/無代碼開發方興未艾，廣大技術、科研人員在這個方向上厲兵秣馬，沒有哪一個方法是 Silverbullet ，也沒有哪一個理論是絕對正確的，只要找到你心中所愛，堅持研究和實踐，終會讓全部人都可以自定義軟件來操做日益複雜和強大的硬件設備，終能讓全部人更加便捷、直接、有效的接入數字世界，終於在本質上將軟件開發和軟件工程領域從新定義！共勉！
原文連接本文爲阿里雲原創內容，未經容許不得轉載。