按照維基百科的說法：
低代碼這個稱呼是 Forrester 在 2014 年提出，指那些用可視化方式創(chuàng)建應用的平臺，特點是代碼量比傳統(tǒng)開發(fā)少的多，甚至無代碼，所以能提高開發(fā)效率。
我用上述方式和團隊伙伴描述低代碼，他們會一臉茫然；因為語言過于專業(yè)甚至聽完之后“似懂非懂”對不對？那如何簡單理解低代碼這件事呢？
在我看來，它更像一種快速開發(fā)應用軟件的系統(tǒng)。
市場或運營人員通過少量代碼甚至無代碼的方式在平臺快速拖拽模塊，構建出協(xié)同表格、采購或生產管理等一些列智能和業(yè)務類的管理系統(tǒng)來滿足日常。
早些年，它的存在是為專業(yè)開發(fā)人員提供支持，幫助他們提取開發(fā)應用過程中繁瑣“底層架構”和“基礎設施”的任務；從而提高開發(fā)效率。
這兩年流行起來的關鍵要素是“協(xié)同關系”的變化；比如：
前線業(yè)務人員想快速構建一套協(xié)同表格來傳達信息，以往只能編輯好“回傳”，在發(fā)送給使用人，現(xiàn)在只需要上云端或者某個系統(tǒng)中直接編輯就可以達到實時更新的效果。
它有顛覆性意義的根本在于客戶一方面在軟件上投入更低，另一方面顯著減低了開發(fā)難度，非專業(yè)人員也能快速使用，充分調動企業(yè)各方面資源，降低對昂貴開發(fā)者的依賴。
代碼可分為三類：1）專業(yè)代碼，2）低代碼，3）零代碼
對于專業(yè)代碼而言，它還有兩個名字，“高代碼”和“傳統(tǒng)代碼”；歸根結底是一回事，形容用傳統(tǒng)方式編寫網(wǎng)頁、應用程程序或者軟件。
如：你開發(fā)某款APP，企業(yè)需要招聘IOS和Android工程師、前端測試，PM等人員共同完成；這意味著開發(fā)者坐下來一行一行的敲擊，并不斷測試修改直到上線。
通常，這種類型的代碼為主要項目服務。當為大量用戶設定特定事物，并定做非常強大且獨立的產品時是種不錯的選擇；但這需要大量的時間、金錢和精力。
那如何寫出高質量的代碼呢？一般有兩種途徑：
其一：先有好的產品經理進行通盤考慮，然后用優(yōu)秀的工程師從底層架構開始搭建，進而把優(yōu)秀的代碼風格延續(xù)下去；猶如蓋大樓，地基決定上層建筑。
其二：從糟糕的工程師開始，不斷進行重構；向優(yōu)秀的設計方案不斷逼近，如同那句話“縫縫補補又三年”，不斷修復與完善。
進一步說，高代碼質量的建設基于優(yōu)秀的商業(yè)模式，產品方案和業(yè)務流程，用例圖，架構圖不斷把關鍵和復雜部分設計出來。
市場需要低代碼的原因是企業(yè)越來越需要通過各種應用（App，小程序）來完善內部的信息流轉，強化與客戶的觸點鏈接；所以，低代碼本身是基于“場景”出發(fā)。
根據(jù)多方調查結果顯示，在大公司內部項目失敗的主要原因之一是缺乏溝通（poor communication）。
傳統(tǒng)開發(fā)模式下，業(yè)務產品、設計開發(fā)、測試與運維人員都有自己的語言，他們各司其職，這造成長期以來很容易形成一個個“豎井”（silos），讓跨部門的溝通變得困難而低效。
這也是當下為什么熱門的敏捷開發(fā)和DevOps都在強調溝通，前者協(xié)同是生意，后者協(xié)同是組織和流程。
連經典的DDD（領域驅動設計）也在強調通過統(tǒng)一語言來減少業(yè)務和技術人員的溝通成本；因此，有低代碼后可以從根本改變，各種角色在統(tǒng)一平臺緊密協(xié)助。
這種全新方式不僅打破職場豎井，還能通過可視化的語言和單一的應用（頁面/數(shù)據(jù)/邏輯），輕松對齊項目進度，從而實現(xiàn)敏捷開發(fā)模式；所以，統(tǒng)一視角的業(yè)務協(xié)同下，它有三個優(yōu)勢：
1）人員聚合，2）應用聚合，3）生態(tài)聚合。
首先，將所有工作人員統(tǒng)一聚集到低代碼平臺進行作業(yè)，促進流程標準規(guī)范化；其次企業(yè)內容各應用的數(shù)據(jù)是天然互動，通過聚合的方式打通能消除數(shù)據(jù)孤島問題。
再者當?shù)痛a平臺聚合足夠多的開發(fā)者，會形成無限想象力的生態(tài)體系；這無疑也是流程再造的根本。
最后說下零代碼（Zero-Code / No-Code），從分類角度看零代表是完全不需要寫代碼的應用開發(fā)平臺；這并不代表它要比低代碼先進，它只是做了一個更極端的選擇而已，徹底擁抱簡單的圖形可視化，完全消滅復雜的文本。
舉個例子：
很多準新人結婚會找“婚慶機構”咨詢關于場地布置問題，以前策劃師在手寫筆記本上通過畫圖為客戶展示效果。
有零代碼后，他只需基于平臺的場景拖拽各種可視化素材，直接給出直觀展示。
選擇零代碼背后的原因是，公司期望盡可能降低應用人員的開發(fā)門檻，讓每個人都能成為開發(fā)者；這里有個概念我們要清晰，“開發(fā)不等于寫代碼”，它是基于業(yè)務構建協(xié)同流程。
要知道，從專業(yè)角度出發(fā)即使非常專業(yè)的開發(fā)者，技術分工精細化的趨勢下（前端/后端/算法/運維）企業(yè)也很難做到獨立開發(fā)和運維整套復雜應用的全棧工程師，但零代碼能改變這一切。
但它也有局限性所在；比如：
一方面可視化的編輯器的表達能力遠不如圖靈完備的通用編輯語言，不引入代碼根本無法實現(xiàn)靈活定制和拓展；另一方面由于目標受眾是非專業(yè)人員，平臺能支持的系統(tǒng)也是傻瓜式。
這只能做到大業(yè)務的組件簡單堆疊，不支持顆?；咏M件和靈活的布局；就好比你想更改一個icon的清晰的都很難。
總而言之，高代碼構建更高維度的業(yè)務和產品，零代碼是低代碼的子集，目前從市場看普適性和適用性均還未達到紅海效應；而低代碼則滿足少開發(fā)的場景使用。
可以說，自2021年1月釘釘落地“低代碼”應用之后很多人才開始關注此賽道。
有人認為低代碼革命來臨，也有人說低代碼可能導致程序員失業(yè)，如果把時間拉長看也許你就不這么認為。
從發(fā)展來看它經歷四個時間：
1980年IBM的快速應用程序RAD出現(xiàn)，2000年可視化編程迭代，2014年Forrester提出低代碼概念。
2016年國內相繼發(fā)布低代碼平臺，2018年Gartner提出aPaaS和iPaaS的概念后市場逐步穩(wěn)固。
由此可見此領域許多玩家早在幾年前就已經存在，比如國外低代碼領域一個巨頭OutSystems這家公司成立在2001年；FileMaker更是誕生在1985年。
所以，廣義上看它屬于SaaS中的分支，但成長速度和SaaS路徑對比明顯要慢很多；總之低代碼雖然說的很好，但市場發(fā)展并樂觀；原因歸屬兩個層面：1）技術成熟度，2）業(yè)務收益低迷。
RAD（快速應用開發(fā)）、BPMS（流程）、可視化開發(fā)、模型驅動這些專業(yè)工具和名詞都有漫長歷史，它們是低代碼組成的必要條件，融合在一起顯然是新瓶裝舊酒，對不對？
或者你理性一點就不會這樣思考，原因是1980到2015年這段時間低代碼技術能力弱，表現(xiàn)亮眼的平臺少之又少國內產品也尚未成型。
但由于投入成本沒那么大，此期間也就為很多平臺打下基礎；直到2015-2018年AWS、Google、Microsoft和Oracle等巨頭和資本入局市場才開始升溫。
看過經典管理書籍《跨越鴻溝》你會明白任何的技術都會遵守所謂的“技術成熟曲線”（The Hype Cycle）。
也就是說：你不可能一出生就直接跳過發(fā)育階段嗨翻全場被大規(guī)模采購和運用，是不是。
比如以模型驅動技術為例，雖十幾年前就有“理論體系”和“配套工具”的研究，但在技術背景下，由于能力不完備過于理想化等原因一直沒能在工業(yè)界走向主流。
從現(xiàn)在視角看，支撐低代碼的“老技術”已經通過幾十年的醞釀打磨變得穩(wěn)固，另一些完美互補的新技術（e.g.云原生、響應式web）均慢慢走向成熟，加上企業(yè)線上數(shù)字化的渴求，那低代碼也就順水推舟。
即使幾十年的低代碼技術已經足夠成熟，也一定在當年市場中產生現(xiàn)在的影響力，這是為什么？
因為技術都是為業(yè)務服務的，早些年應用開發(fā)業(yè)務要比現(xiàn)在簡單，且需求者多半為「技術人員」而非現(xiàn)在市場、運營等其他崗位的人。
其次當年也沒有如今的多渠道，多樣化體驗和集成定制等需求，更不會成為企業(yè)級的標準配置，所以更缺乏快速變化的IT業(yè)務場景來推動交付。
雖然低代碼可以解決多端應用生成、云原生架構、API集成；可放在當年業(yè)務背景下，加上技術不成熟；顯然整體的投入產出會有所下降，這不足以讓企業(yè)大面積采購來做解決方案。
如今不同，從外因講，中大企業(yè)的數(shù)字化服務市場，經過幾十年發(fā)展進入增長瓶頸期，不能從平臺角度滿足軟件服務企業(yè)的業(yè)務增長需求，需要開辟新的賽道，于是中小企業(yè)的數(shù)字化轉型就被挖掘出來。
從內因角度出來，中小企業(yè)數(shù)字化轉型迫在眉睫，黑天鵝導致轉型進行的提前；以傳統(tǒng)餐飲為例，他們需要建立在線訂餐、客戶管理、營銷管理、員工辦公等各種系統(tǒng)。
目前市面的中小公司有兩種狀態(tài)：
1）瘋狂踩坑，2）一張白紙。
前者他們吃過各種定做APP、小程序/H5的虧，投入巨大收入效果甚微；后者初創(chuàng)公司想做技術，但又沒有較多成本預算花在人工運維上。
除此外，對大公司來說，想開發(fā)款軟件內部流程環(huán)節(jié)復雜，這無疑沒辦法快速試錯。
據(jù)此在內因、外因的共同作用下，低代碼成為被風口選中的行業(yè)；加上資本的涌入無疑就火爆起來。
查理·芒格有個經典的思維模型叫做“10-10-10”原則。
講的是在決策時思考三個問題，即：這個決策在10分鐘后會產生什么影響？10個月后、10年后呢？在我看來，低代碼的價值短期被高估，長期被低估。
為什么？不妨我們看一組詳細數(shù)據(jù)。
全球權威的技術研究和分析公司Gartner發(fā)布的《2021年中國ICT技術成熟度曲線報告》（以下簡稱“報告”），首次將低代碼應用開發(fā)平臺（LACP）作為新興技術熱點被納入。
帆軟旗下產品簡道云憑借完善的產品和輕量級的交付被入選LCAP （代表廠商），也是國內首家。
Gartner的報告研究常規(guī)覆蓋20多項新型技術和實踐，也就是說在過去幾十年中低代碼并未能夠真正拿出臺面；而今天居然以新賽道的方式出現(xiàn)，這無疑反應該技術在全球的崛起與未來增長的潛力。
《2021年中國ICT技術成熟度曲線報告》
把視野放到國內，從行業(yè)規(guī)?？?，2021年海比研究院數(shù)據(jù)表明中國低代碼廠商約有120家，IT桔子盤點投融資情況達15起。
預計到明年能達到200家的體量；以頭部為代表的有簡道云、明道云、帆軟、飛書、金蝶等。
從市場份額角度出發(fā)，今年低代碼規(guī)模達到28.5億；未來五年復合增長率為49.5%，明年可達42.6億；2025年預計達到142.2億；從使用者需求，低代碼平臺被分為四種類型：
1）場景應用型，2）產品研發(fā)型
3）平臺生態(tài)型，4）技術賦能型
場景應用是為具體細分領域業(yè)務而打造，開發(fā)側重于企業(yè)自用；生態(tài)屬于頭部布局中軟件的某一分支；技術支持則代表更底層的算法、區(qū)塊鏈等方面的協(xié)同；收入模式占比最高的是前三者。
我們能得出什么啟發(fā)呢？
低代碼在全球視角下經過幾十年沉浮，終于以穩(wěn)定增長模式進入大眾視野并且被市場所認可；智遠根本兩則“報告”總結，認為呈現(xiàn)三種趨勢：
首先，2020年將會有40%-60%的企業(yè)使用低代碼開發(fā)應用，其次企業(yè)從獨立研發(fā)APP開始向數(shù)字化平臺轉變，并且將大企業(yè)數(shù)字化應用作為基礎設施。
再者大量平臺的出現(xiàn)，會加速企業(yè)核心業(yè)務的系統(tǒng)開發(fā)；進一步說，低代碼能夠支撐起高復雜度，高技術、超大規(guī)模的應用開發(fā)。
并且將整個鏈路覆蓋到以客戶管理、運營流程、生產、配送為代表的核心業(yè)務部分；這種結構性的變化并且還會持續(xù)細分。
由此可見，頭部巨頭正在以生態(tài)為中心引入“低代碼”廠商；整個大市場熱度呈現(xiàn)先抑后揚；國內這么多家低代碼公司突出賽道的關鍵點在于：1）產品使用門檻要低，2）行業(yè)積累要深耕。
也就是說：低代碼公司和巨頭平臺結合，找到某個點切入細分和小眾市場，聚焦一個領域做深做透；深度運營和培訓客戶并建立壁壘，才能實現(xiàn)長期主義共贏。
資本有好有壞，難免也讓“創(chuàng)業(yè)項目”變形。
因為創(chuàng)始人的對賭協(xié)議想快速回籠資金而忽略產品體驗的公司不計其數(shù)，有些則默不作聲的打磨技術，在市場沒有任何聲音也很多。
在混戰(zhàn)的低代碼江湖中，中小企業(yè)要不要用低代碼或怎么選適合自己公司的產品呢？這里有三個思考：
首先如前所述，目前屬于行業(yè)爆發(fā)期，夸張點看似乎沒有一家低代碼公司不說自己是“專業(yè)軟件”公司的；那么，借此風口來搶杯羹的大有人在。
假設因為預算而選擇家新創(chuàng)立或“團隊基因”一般的公司，可能以后在數(shù)據(jù)和產品使用方面的坑會踩不完。
我并非說“新創(chuàng)立”的公司不行，而是我們要看準合伙人資歷，對行業(yè)思考以產品定位等各要素；那大公司或上市公司背景就一定好嗎？未必。
有些企業(yè)雖有歷史但通過兼并收購方式買下某個產品是為補齊每年財報短板，營收業(yè)務開展方面顯得好看。
所以他們通過此手段趕緊發(fā)布低代碼平臺好抓緊搶占客戶，技術方面肯定不行的，無疑你就成了小白鼠。
其次是產品的發(fā)布時間，一般來看2015年左右的公司無疑在此行業(yè)算做足詳細調研。
因為2015年左右低代碼經歷過一次低谷期，也許當時他們前身并非是該行業(yè)，但能確定押注此賽道并活到現(xiàn)在說明創(chuàng)始團隊的眼光具有前瞻性。
再者從公司內部出發(fā)，落地某個項目時難免會遇到今天開發(fā)的功能沒用上，過段時間發(fā)現(xiàn)此功能又有用，所以版本的管理也很重要。
有些企業(yè)雖內部運用該軟件，但能否支持協(xié)同開發(fā)還是有必要的；除非是內部特別小驗證的項目，這方面我相信負責過項目的人應該非常感同身受。
不論從高管視角還是業(yè)務出發(fā)，很多公司整體認知對“低代碼”并沒有概念；即“他們不知道這個東西是什么”或“我用它解決什么問題”；當對產品了解后才知道“原來可以這么干”。
一般來說，企業(yè)不會用低代碼從零開發(fā)整套核心業(yè)務，比如ERP/CRM、甚至BOS智慧運營系統(tǒng)等；如果需要直接買套成熟解決方案即可。
所以就目前而言，低代碼更適合核心數(shù)字化系統(tǒng)之上，構建創(chuàng)新類的應用和敏捷運營類的運用；用最土的話表達是“解決企業(yè)到用戶之間最后一公里的事情”。
那么比較適合用低代碼的場景有哪些呢？我總結為5大方面：1）門戶端，2）數(shù)據(jù)操作和展示端，3）業(yè)務流程端，4）移動端，5）基于所有表格的運用
門戶包含APP，小程序，PC網(wǎng)站；數(shù)據(jù)方面包括通過鏈接企業(yè)內部的數(shù)據(jù)庫把生產經營打通，進行展示和簡單互動沉淀；業(yè)務流程包含跨部門協(xié)助、OA審批、人力財務等。
舉個例子：
現(xiàn)在要辦場1000人規(guī)模的行業(yè)大會，我們可以通過低代碼構建人員分工，物料明細和協(xié)同進度完成整體策劃執(zhí)行，它可以像OKR一樣讓所有人看到每個人都在做什么，從而來相互配合。
在移動端具體表現(xiàn)有核心經營系統(tǒng)管理系統(tǒng)，如考勤打卡；表格運用場景相對比較多，譬如基于數(shù)據(jù)庫的表單收集整理、統(tǒng)計處理等。
這是我從市場運營視角出發(fā)的角度整理，不難看出，以上五種類型算是覆蓋企業(yè)80%的數(shù)字化系統(tǒng)，除此外還覆蓋更多行業(yè)基本面，如教育、文旅、零售、金融等，不一而論。
通過分析國外的低代碼領導型公司，可以得出他們在業(yè)務上的創(chuàng)新方式是“組合式”。
比如Outsystems之前是做BPM（業(yè)務流程管理），SAP、Microsoft之前是做aPaas和MADP（移動開發(fā)平臺）的重組，Kony也是做相似。
由此可見，把BPM，可視化和aPaas融合加上組件云原生經歷市場打磨才形成“低代碼”平臺；所以說這三種能力是國內公司也不可缺失的，總結為：1）MADP，2）可視化，3）aPaas
第一：大部分低代碼平臺基于模型驅動橫跨平臺開發(fā)能力，MAP能夠更好地應對中小公司數(shù)字化業(yè)務和創(chuàng)新的需求，持續(xù)演進的組件可根據(jù)需求快速建立新的建模器和產品服務。
第二：“可視化拖拽編輯器”是基本配置，若這方面不能解決就不能稱為低代碼平臺，難道讓一個收銀員或運營寫英文表格嗎？顯然不現(xiàn)實。
第三：aPaas是PaaS（平臺即服務）的子形式，它能支持應用程序在云端開發(fā)和部署，能提供軟件開發(fā)中的基礎工具給用戶，包括數(shù)據(jù)對象、權限管理、用戶界面等；沒有此能力企業(yè)無法私有化部署。
基于三者之上所謂的一體是什么呢？即：配套的生態(tài)。
換句話說，通過此低代碼平臺能不能完成和其他云與企業(yè)內部的數(shù)字化鏈接打通的能力很重要。
總而言之，不同平臺都有自己的定位，假設沒有這三者基礎我想企業(yè)沒必要選擇，從價值鏈角度出發(fā)，它也是基于企業(yè)數(shù)據(jù)產生“信息環(huán)”當中必要的一環(huán)。
總結一下：
我們會看到各種新技術（算法）、模型和產品的問世，復雜的讓人難以理解對不對？
但好像它們都逃脫不了舊公司和新產品的組合；或新公司裝舊產品使用“新宣言”。
任何B2B企業(yè)以客戶需求為核心出發(fā)進行場景細化，萬變不離其宗好；你看，時間從不語，卻回答了所有問題。
本文來自微信公眾號“王智遠”（ID:Z201440），作者：王智遠，36氪經授權發(fā)布。
