低代碼究竟是什麼—
這些年，自從 SaaS（Software-as-a-Service） 廠商 Salesforce 市值水漲船高，還和其大手筆的商業併購案，逐漸引起了國內互聯網行業人的關注，習慣進行國內外產品對標的互聯網圈子興起了一股 SaaS 風潮，在後移動互聯網時代下，部分人也期待 SaaS 可以成爲國內互聯網的一個新增長點。
隨着不同的用戶訴求，一些系統衍生出新的形態，不同於既定的 SaaS 產品形態，用戶可以通過可視化拖拽界面、表單配置等方式，快速定製出一個完整的應用，而且這一類系統基本不用編寫太多的代碼，即可以實現定製化應用。隨着這一形態的系統越來越多，久而久之，大家就形象地稱之爲 “低代碼”（low-code），另外也有人稱之爲 ”aPaaS“，即應用平臺即服務（屬於是互聯網造詞老技能了...）。
低代碼這個概念真正火熱起來，還是在於這兩年 Outsystems 相繼完成了數輪過億元美金的融資，估值早早地站上了十億美金級別，成爲一方獨角獸。由於國內這一領域缺少體量對等的廠商，所以大家自然也在期待哪家廠商能成長爲中國的 Outsystems。與此同時，國內低代碼賽道上選手也漸漸進入了大家的視野，例如釘釘宜搭、即刻應用、氚雲、簡道雲等等。
低代碼系統長什麼樣—
雖然低代碼平臺的形態很多，但是其中的核心還是脫離不開編程思想，基本都有以下功能模塊：頁面搭建、數據邏輯、數據模型，在線部署和管理系統。根據不同的業務場景，具體的平臺形態分化爲表單/數據模型驅動、界面驅動等形態。
表單/數據模型驅動
表單/數據模型驅動是圍繞數據結構來定義整個應用的形態和流程，其中表單驅動指用戶通過配置表單界面，元素大多是文本輸入、下拉選擇器、日期選擇器等組件，配置表單界面後自動生成數據模型，並基於該表單做數據及流程管理，而數據模型驅動則更復雜，需要用戶進行數據建模和定義模型關係，此操作和 SQL 數據庫搭建類似，配置主鍵、索引，類型等等，然後基於該數據表單搭建上層的管理系統。該模式比較多應用在搭建 CRM、ERP 等管理系統。
界面驅動
界面驅動比較好理解，就是用戶通過拖拽組件方式可視化搭建界面，然後配置頁面的交互邏輯，比如頁面的跳轉、數據獲取等等。這種形式大多應用在搭建通用程序的低代碼平臺
這種模式與端應用開發的套路基本一致，只是將代碼編輯修改爲畫布拖拽和表單配置。這裏舉一個簡單的例子，在界面按鈕設置一個點擊事件，事件邏輯爲拉取數據。該流程就是將編程概念提取爲交互表單操作，裏面還是會出現入參出參字段、回調等等概念，遵循編程的思想。
應用上線
當用戶將應用搭建完成後，可以直接在平臺上完成發佈工作，然後就可以通過給出的鏈接訪問應用（大多數低代碼平臺製作出來都是 web 應用）。這一步也十分關鍵，在常規的流程裏面，一個應用的上線，需要投入很多的精力去配置相關的線上環境和服務，這個操作具有很強的專業性，普通用戶很難獨自完成。低代碼平臺將這一環節打通，大大降低了使用門檻。
低代碼概念雖然比較新穎，但是低代碼平臺已經發展了很久了（Outsystems 建立於 2001 年，國內的道一雲建立於 2004 年）。總體來說，經過這些年的發展探索，低代碼平臺的形態也趨於穩定，各家的創新也是基於面對的用戶場景而實現的，本質上還沒有跳脫出編程思想。
低代碼怎麼做個性化定製—
這裏有同學會問了，低代碼平臺怎麼滿足個性化需求？誠然，受限於低代碼平臺所提供的組件和邏輯配置表單，只能解決一些通用化場景，當用戶的訴求超脫出這個圈圈時，是不是就無能爲力了？商業公司肯定不會這麼幼稚，以下簡單列舉蒐集到的一些個性化定製的方法：
-
用戶可以在平臺定製的規則下錄入組件 -
提供 API 訪問數據庫做定製開發 -
生成源代碼做二次開發 -
填寫反饋等平臺更新
除了這些固定的章程，無論體量大小，低代碼廠商還有大量的客戶專員，跟進用戶的使用情況，詢問訴求等等，後續可以根據用戶訴求給出合適的配置方案，乃至專門定製個性化場景。到這裏就聞到了一絲外包公司的氣味，不過這確實符合實際用戶的訴求，最重要的是一個可以帶來收入的場景。
低代碼有沒有用？—
“低代碼究竟有沒有用？”
這個問題浮現在各個論壇上。這個問題可以理解爲低代碼的聲量和其能力不匹配，用戶對低代碼信心不足。對於目前低代碼平臺的問題，存在主觀和客觀的因素。
首先很多低代碼平臺能力還沒有足夠完善成熟，這是一個很核心的因素。對於很多初次使用的用戶來說，概念繁多，邏輯複雜，在一番體驗以後，預期和實際有落差。使用起來總體耗時跟源碼開發相差無幾，顯得工具比較雞肋。客觀上，國內的人力資源情況相比歐美還是比較便宜，很多有定製應用訴求的客戶，首先會想到的是找外包，或者招聘開發崗位，而不是找低代碼工具自己動手。另外大家對於低代碼的認知也還不足，很難成爲一個備選項。
思考這個問題，我們想一個簡單問題，“一個可以降低門檻，提高效率的工具有沒有用”，答案很顯然是肯定的。低代碼平臺的宗旨，不就是“降低門檻”，“降本增效”麼。
個人覺得，這些問題大概是時間的問題。就目前市面上的低代碼工具而言，從實際需求出發，當深入體驗過以後，其實是可以深切感受到工具帶來的紅利。花上幾天，一個人就可以實現前後端應用，以及運維監控，拿到一套可運行的程序。
隨着行業關注度的提升和資源的投入，上述遇到的問題大多可以得到解決。低代碼從“可用”到“好用”的進化，也是需要在實際場景中摸爬滾打中歷練進化。
目前低代碼發展狀況—
前面說了，低代碼的熱度持續提升，最明顯的舉動就是資本真金白銀的投資。
除了在資本上的行動以外，可持續性的收入也很重要。低代碼這一特性，註定很難通過流量來實現盈利，低代碼不是做慈善，所以很多低代碼廠商自然而然地將目光投向了拓展 B 端客戶，B 端羣體的付費意願比普通用戶強多了。只要打開各個廠商的官網，就可以看到琳琅滿目的合作案例。這也就解釋了爲什麼低代碼廠商常常會擁有龐大的客戶服務崗，生存的壓力也促使他們必須要這麼做。
另外有一個舉動也很巧妙。釘釘發佈了一個低代碼聚合平臺，宜搭、氚雲、簡道雲、易鯨雲等頭部低代碼廠商入駐。釘釘擁有國內最大的商務用戶人羣，而低代碼在國內比較成功的落地場景是定製企業管理系統（例如 CRM），將低代碼平臺對接到巨大的對口流量之上，這種契合的操作頗有幾分微信接入微信支付一般痛快。
雖然目前發展勢頭不錯，但是打鐵還需自身硬，避免共享經濟那樣一地雞毛。低代碼只有切實地把門檻降低、降本增效目標落在產品上，纔可以長久地生存下去。
我們的探索嘗試—
Deco 智能代碼項目（ling-deco.jd.com）是我們團隊在「前端智能化」方向上的探索，我們嘗試從設計稿生成代碼（Design To Code）這個切入點入手，通過 AI 的手段，對現有的設計到研發這一環節進行能力補全，進而提升產研效率。
在一個日常需求開發流程中，對於前端工程師來說，輸入源是視覺稿 + PRD，輸出結果是可上線的頁面代碼。而在 Deco 的開發模式下，直接從設計稿轉化成前端頁面，然後通過可視化畫布和表單配置配置頁面的邏輯，最終輸出可運行的多端代碼。
更多信息，歡迎大家訪問下面的鏈接進行了解：
http://ling-deco.jd.com
本文分享自微信公衆號 - 凹凸實驗室（AOTULabs）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。