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