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