什麽是低碼？
什麽是“低碼”？如果是第壹次聽說，大概和我從老板那聽到壹句話後的內心戲是壹樣的:什麽？“低碼”？“代碼”就是代碼的意思，我知道，但是“低”這個詞是什麽意思？不會是老板發現我匆忙寫的代碼又醜又“低”吧...我想多了，那老板怎麽自己審核代碼呢？那是指“低級編程”中的“低”嗎？老板終於覺得讓我和其他編程奇才整天堆Java業務代碼太浪費了，派我去寫壹個高性能的C語言網絡庫...顯然不是，老板怎麽會有這種技術感？這到底是什麽意思？作為壹個商比情商高的程序員，凡是能問谷歌的，絕對不會問老板。於是壹次操作之後，我不假思索的打開了第壹個搜索結果:低代碼開發平臺。
維基百科定義
從維基的這個定義中，我們可以提取幾個關鍵信息:
●代碼開發平臺(LCDP)也是壹種軟件，它為開發者創建應用軟件提供了壹個開發環境。看到“開發環境”這幾個字親切嗎？對於程序員來說，低代碼開發平臺的本質和IDEA、VS等代碼IDE(集成開發環境)幾乎是壹樣的，都是為開發者服務的生產力工具。
與傳統的代碼IDE不同，低代碼開發平臺提供了壹個更高維度的、易於使用的可視化IDE。大多數情況下，開發人員不需要使用傳統的手寫代碼進行編程，而是可以通過圖形化拖拽、參數配置等更高效的方式完成開發工作。
Forrester定義
根據Wiki的描述，可以發現“低代碼”壹詞早在2014年就由Forrester提出，其對低代碼開發平臺的祖先定義如下:
請點擊輸入圖片說明。
與Wiki版本相比，這個定義更傾向於闡明低代碼帶來的核心價值:
低代碼開發平臺可以實現業務應用的快速交付。換句話說，不僅僅是“能夠”像傳統開發平臺壹樣開發應用，低代碼開發平臺的重點是更快地開發應用。更重要的是，這個速度是顛覆性的:根據Forrester在2016年的研究，大多數公司反饋低代碼平臺幫助他們提高開發效率5-10倍。而且，我們有理由相信，隨著低碼技術、產品和產業的不斷成熟，這種推動因素還能繼續上升。
低代碼開發平臺可以降低商業應用的開發成本。壹方面，低代碼開發在整個軟件生命周期過程中的投入更低(代碼編寫更少，環境設置和部署成本更簡單)；另壹方面，低代碼開發大大降低了開發者的使用門檻。非專業開發人員經過簡單的IT基礎培訓即可快速上崗，不僅可以充分調動和利用企業各方面的現有人力資源，還可以大大降低對昂貴的專業開發人員資源的依賴。
低代碼核心能力
基於以上定義和分析，不難總結出低代碼開發平臺的以下三個核心能力:
請點擊輸入圖片說明。
全棧可視化編程:可視化包含兩層含義，壹是編輯時支持的點擊、拖動、配置等操作，二是編輯後所見即所得的預覽效果。傳統的代碼IDE也支持壹些可視化能力(如早年Visual Studio的MFC/WPF)，但low code強調全棧、端到端的可視化編程，涵蓋了壹個完整應用開發所涉及的所有技術層面(接口/數據/邏輯)。
生命周期管理:作為壹站式應用開發平臺，low code支持應用的完整生命周期管理，即從設計階段(部分平臺還支持更高級的項目和需求管理)，經過開發、構建、測試、部署，到上線後的各種運營(如監控報警、應用上線下線)和運營(如數據報表、用戶反饋)。
代碼擴展性低:用低代碼開發時，大多數情況下仍然離不開代碼，所以平臺必須能夠在必要時用少量代碼支持應用級別的靈活擴展，比如添加自定義組件、修改主題CSS樣式、自定義邏輯流程等。壹些可能的需求場景包括:UI樣式定制、遺留代碼重用、特殊加密算法、非標準系統集成。
不僅僅是寫更少的代碼。
讓我們回到最初小白的問題:低碼中的“低”是什麽意思？答案是顯而易見的:不是說抽象程度很低(恰恰相反，低代碼開發的抽象程度高於傳統編程語言)，也不是說低代碼生成的代碼很低(恰恰相反，低代碼生成的代碼壹般都經過精心維護和反復測試，整體質量優於大多數手寫代碼)，而是簡單地“少寫代碼”——少數情況下只使用手寫代碼，大部分時間可以使用可視化等非編碼。
往深裏看，低代碼不僅僅是少寫代碼:代碼寫得越少，bug越少(所謂“少做少錯”)，所以開發過程中少了兩個支柱任務:“趕需求”和“修復bug”；要測試的代碼更少，所以可以少寫測試用例；平臺除了開發階段，還涵蓋了後續的應用構建、部署和管理，因此運維操作較少(低代碼→低運營)。
但是，少並不是最終目的:如果單純想達到少的效果，削減需求，減少人力，降低質量要求都是壹樣的。低代碼背後的哲學是少即是多，或者更準確地說，用更少的資源做更多的事情——更多的能力、更快的上線、更好的質量和更低的成本，這深刻地踐行了阿裏“既要又要”的價值觀的精髓。
請點擊輸入圖片說明。
平臺的責任和挑戰
以上是低代碼給開發者提供的能力和吸引力，那麽作為服務提供商和應用載體，低代碼開發平臺本身應該承擔哪些責任，會遇到多大的挑戰？有必要像阿裏雲倡導的那樣“把復雜的留給自己，把簡單的留給別人”嗎？雖然這句話聽起來很深刻很清晰，但不知道大家有沒有想過，為什麽壹定要抓住復雜不放，平白無故的給自己找東西。難道我們就不能把復雜的幹掉，把壹些簡單的東西留給阿裏雲自己的員工嗎？是工作太容易體現KPI的價值，還是家裏的飯菜沒有公司的宵夜香？
苦思良久，我從熱力學第壹定律中找到了答案:開發壹個應用的總復雜度是恒定的，只能轉移不能消失。如果開發者想做的更少，享受簡單的快樂，那麽平臺方就得做的更多，默默承擔盡可能多的復雜。就像壹個渾身是筋的雜技演員，穩穩地托起正在高空旋轉跳躍的女伴；上面的人顯得越輕盈、越不費力，下面的人就越穩重、越疲憊。當然，並不是說上面這些女星都很放松，沒有壓力，只是她們各自的分工不同，復雜程度不同。
根據《人月神話》作者弗雷德·布魯克斯的劃分，軟件開發的復雜性可以分為本質復雜性和偶然復雜性。前者是解決問題所固有的最小復雜度，與妳使用什麽樣的工具、經驗是否豐富、架構好不好無關，後者是實際開發過程中引入的復雜度。壹般來說，本質復雜性與業務要解決的具體問題域有很強的相關性，所以我稱之為“業務復雜性”，在這裏更好理解；這部分復雜性是任何開發方法或工具都無法解決的，包括低代碼。偶然復雜性壹般與開發階段的技術細節有很強的相關性，所以我相應地稱之為“技術復雜性”；而這部分復雜性正是low code所擅長和適合解決的。
作為低代碼開發平臺，盡可能屏蔽底層技術細節，降低不必要的技術復雜度，支持其更好地應對業務復雜度(滿足靈活通用的業務場景需求)，是開發者的核心職責。
請點擊輸入圖片說明。
在履行上述職責的同時，低代碼開發平臺作為面向開發者的產品，還需要致力於為開發者提供簡單直觀的極致開發體驗。除了這背後巨大的工作量，我們還必須在“功能強大”和“易於使用”這兩個矛盾之間，努力找到我們的產品定位和目標客戶需求之間的平衡——這可能是設計壹個通用低代碼開發平臺的最大挑戰。
三、低碼相關概念的比較
純代碼(專業代碼/定制代碼)
“純代碼”可能是我發明的壹個詞。更常見的是，它是親代碼或定制代碼。但意思是壹樣的，就是指傳統的以代碼為中心的開發模式。之所以選擇使用“純代碼”，是因為如果使用“專業代碼”，會顯得low代碼不專業，而使用“自定義代碼”則容易讓人誤解為low代碼無法支持定制的自定義代碼。
當然我覺得更準確的名字是“高碼”(正好對應低碼，但是名字太難聽了，所以不喜歡...)，因為即使使用傳統的代碼IDE，有些開發工作也支持(甚至更適合)非代碼補全，比如iOS開發中使用的SwiftUI界面設計器，數據庫應用的服務器開發中使用的PowerDesigner建模工具。但這部分可視化工作在傳統開發模式下只是起到輔助作用，最後通常生成開發者可以直接修改的代碼；開發人員仍然關註代碼來執行他們的主要工作。
低代碼和純代碼的關系其實很像視頻和文章的關系:
低碼就像現代的“視頻”。大部分內容由圖片組成，直觀易懂，表現力強，因此更容易被大眾接受。但同時，視頻不夠剛性，不能有圖片，可以加入少量文字(如字幕、註解)來彌補圖片表達不準確的問題。BTW，關於“圖”與“文”的辯證關系，可以進壹步參考《建築制圖:工具與方法論》[1]壹文中的相關描述。
純代碼更像是傳統的“文章”。雖然長期以來壹直是信息傳播的唯壹媒介，但隨著視頻技術的誕生和相應軟硬件基礎設施的普及，逐漸被搶了風頭。如今，視頻已經成為大多數人獲取信息的主要渠道(從電視和電影到嗶哩嗶哩和Tik Tok)，但越來越少的人經常閱讀書籍和文章。但不可否認的是，文章還是有它的意義和受眾的(不然我也不會費心打那麽多字)。即使“市場份額”受到了擠壓，也總會有它立足的空間。
請點擊輸入圖片說明。
按照上面的類比，low code未來會走類似於視頻的發展軌跡，超越純代碼成為主流發展模式。Gartner的預測也表達了同樣的觀點:到2024年，所有應用程序開發活動的65%將由低代碼完成，75%的大型企業將使用至少四種低代碼開發工具進行應用程序開發。
但同樣，就像視頻永遠無法取代文章壹樣，低代碼永遠無法完全取代純代碼開發。未來，低碼和純碼模式將以互補的形式長期存在，各自在適合的業務場景中大放異彩。在後面的“低代碼業務場景”壹章，我們會詳細列出現階段哪些場景更適合用低代碼模式開發。
零代碼/無代碼
從分類的完備性來看，如果有“純代碼”，自然也應該有完全相反的“零代碼”(也叫“無代碼”)。零代碼是壹個完全不需要寫代碼的應用開發平臺，但並不意味著零代碼比低代碼更高級、更高級。它只是做了壹個更極端的選擇:完全擁抱簡單的圖形可視化，完全消除復雜的文本代碼。選擇背後的原因是希望零代碼開發平臺盡可能降低應用開發的門檻，讓每個人都能成為開發者(註:開發≠寫代碼)，包括業務分析師、用戶運營甚至是根本不懂代碼的產品經理(裝不懂就是不懂)。
即使是專業開發者，在技術分工越來越細的趨勢下(前端/後端/算法/SRE/數據分析...)，很難招到壹個能獨立開發和維護壹整套復雜應用的全棧工程師。但零代碼可以改變這壹切:無論是分不清Java和JavaScript的技術小白，還是精通深度學習卻沒有時間學習Web開發的算法大牛，都可以通過零代碼實現自己的技術夢或者全棧夢。“改變世界的想法就在那裏，只需要壹個程序員”，這個笑話可能真的會成真；哦，不，妳甚至不需要壹個程序員。有想法的人可以自己做。
請點擊輸入圖片說明。
當然，所有的選擇都是有代價的，零碼也不例外。完全放棄代碼的代價是有限的平臺能力和靈活性:
壹方面，可視化編輯器的表達能力遠不及圖靈完整的通用編程語言，不引入代碼無法實現靈活定制和擴展(當然理論上也可以做成類似Scrach/Blockly的圖形化編程語言，但那只是手寫代碼的另壹種形式)。
另壹方面，由於目標受眾是非專業開發人員，平臺所能支持的操作會趨於“愚蠢”(如頁面只支持大型業務組件的簡單堆疊，而不支持細粒度的原子組件和靈活的CSS布局定義)，同時，只會展現相對“人性化”的模型和概念(如使用“表格”來表示數據，而不是“數據庫”)。
請點擊輸入圖片說明。
雖然狹義的零碼和低碼有明顯的區別，但廣義的零碼可以看作是低碼的子集。Gartner在其相關研究報告中，只是將“無代碼”歸為更廣泛的低代碼應用平臺“LCAP”。目前市面上很多常見的低代碼開發平臺也有壹定程度的零代碼能力；比如低代碼領域的領軍企業Mendix，不僅提供了簡單易用的零代碼Web IDE——Mendix Studio，還包含了更強大的低代碼桌面IDE——Mendix Studio Pro。
高生產力應用程序平臺即服務
如上所述，“低代碼”這個詞是Forrester給出的。作為國際知名的研究機構(又名造詞專家)，Gartner顯然不會在這場可能決定低代碼領域江湖地位的新概念造詞大賽中輕易放棄，所以也在2017發明了“HPA PAAs”(高生產力應用平臺即服務)這個縮寫詞。
根據Gartner的定義，HpaPaaS是壹個支持聲明式、模型驅動的設計和壹鍵部署的平臺，提供在雲上快速應用開發(RAD)、部署和運行的特性。這顯然和低碼的定義壹模壹樣。不過，事實證明，名字起得太專業也不壹定是好事。最終“HpaPaas”敗給了出身更早的“低碼”，更接地氣，更流暢。從2019開始，Gartner也開始在相關研究報告中全面采用“低碼”(如LCAP)壹詞，並親自為“HpaPaaS”標註@ dep。
請點擊輸入圖片說明。
來源:SaaS/IaaS/PAAs/APAAS/HPAPAAs有什麽區別？
值得補充的是，“HpaPaaS”這個詞並不是天生的，而是繼承了Gartner早前提出的“aPaaS”。它們之間的關系是:HPA as只是aPaaS的壹個子類；除了低代碼實現的高生產力應用開發平臺HPA as，aPaaS還包括面向純代碼的傳統應用開發平臺(高控制aPaaS，即控制程度更高的純代碼開發模式)。
不值得八卦的是，“aPaaS”壹詞並非憑空捏造，而是與雲計算的興起有著很深的聯系。相信雲道的各位都猜到了，aPaaS和IaaS/PaaS/SaaS是雲計算的古老概念:aPaaS介於PaaS和SaaS之間，比PaaS提供的服務更具應用性，但並不像SaaS那樣提供現成的軟件服務(更詳細的解釋請參考有圖的出處文章)。
第四，為什麽需要低代碼？
低碼是什麽可能沒那麽重要。畢竟在這個信息爆炸的世界裏，總是缺少新奇短暫的東西。所謂的新技術，大多只是曇花壹現:出現了，被看到了；大多數人“哦”了壹聲，看了卻表示不感興趣；少部分人驚嘆於它的奇思妙想，興奮地稱贊它，轉而想用什麽還是用什麽。真正決定壹項新技術能否轉化為新生產力的，從來都不是技術本身有多優秀多華麗，而是是否真的需要，也就是為什麽需要低代碼？如果把上面的問題用不同的科目來填充(冷知識:這叫“延遲科目初始化”)，可以更全面的看這個問題:
為什麽“市場”需要低碼？
在這個所有大爺大媽都充斥著“互聯網+”和“數字化轉型”的時代，企業越來越需要通過應用(App)來改善企業內部的信息流，加強與客戶的聯系連接。然而，誕生時間不長的IT信息時代也面臨著類似於我國社會主義初級階段的供需矛盾:落後的軟件開發生產力跟不上人民日益增長的業務需求。
請點擊輸入圖片說明。
Gartner預測，到2021，應用開發需求的市場增長將至少超過企業IT交付能力的5倍。面對如此巨大的IT缺口，如果沒有革命性的“新生產力”體系，很難想象僅僅依靠現有傳統技術體系的發展和延續就能徹底解決問題。低代碼技術正是帶著這樣的使命而來，希望通過以下幾個方面徹底革新應用開發的生產力，拯救幾乎處於水深火熱中的IT世界:
提高效率，降低成本&；質量保證
雖然軟件行業壹直在高速發展，新的語言、框架、工具層出不窮，但是作為從業者，我們不得不承認，軟件開發還處於手工作坊的階段，效率低，人力成本高，質量不可控。項目延遲交付已經成為行業常態，瓶頸幾乎都是開發人員(對於機器能解決的問題都不是問題)；優秀的開發人才永遠是稀缺資源，也是賊貴；軟件質量缺陷始終無法收斂，在線故障頻發，導致資金不斷流失。
相比之下，經過上百年的工業革命，傳統制造業大多早已擺脫了對“人”的強烈依賴:從原材料的輸入到產品的輸出，中間有各種精密儀器和汽車生產線的穩定支撐，從而真正實現了生產的標準化和規模化。雖然信息化被譽為人類的第三次工業革命，但軟件產業的現狀遠未達到工業化的成熟階段。
所以，親愛的程序員朋友，當妳壹上午都在和前端調試接口，壹下午都在和產品強行需求，壹晚上都在和自己的bug做鬥爭，最後睡著了被壹系列的報警信息吵醒的時候，妳有沒有仰望星空說:“我有壹個夢想...那總有壹天，軟件開發可以像工業產品壹樣批量生產，穩定高效無憂。”現在，不管妳是否意識到，這個願景正在慢慢變成現實。
請點擊輸入圖片說明。
是的，低代碼正在將應用軟件開發過程工業化:每壹個低代碼開發平臺都是壹個技術密集型的應用工廠，所有項目相關人員在同壹條生產線上緊密合作。開發的主力軍不再是熟悉for循環100種寫法的技術極客，而是壹群有著滿滿想法和商業意識的應用創客。有了各種成熟的基礎設施，有了現成的標準件，有了應用工廠的自動化流水線，開發者只需要專註於核心的商業價值。即使遇到非標需求，也可以隨時自己動手，用最靈活的手工定制(代碼)解決各種邊角問題。
擴大勞動力的應用和發展
low code(包括零代碼)通過讓大部分開發工作僅通過簡單的拖拽和配置即可完成，顯著降低了用戶門檻，使企業能夠充分利用前述的平民開發者資源。在壹些零代碼需求的場景下，低代碼也可以讓業務人員交付自助式應用，既解決了傳統IT交付模式下的任務積壓問題，又避免了稀缺的專業開發資源被大量簡單重復的應用開發需求占用，也讓業務人員真正按照自己的想法實現應用，擺脫了交給別人開發時不可避免的束縛。
請點擊輸入圖片說明。
至此，應用開發能力不再是少數專業開發者的專利和特權，未來所需的技能門檻和擁有成本會越來越低，真正實現所謂的“技術民主化”。
在開發過程中加強溝通與合作。
多方調查的結果表明，軟件項目失敗的壹個很重要的原因就是溝通不暢。在傳統的開發模式下，業務、產品、設計、開發、測試、運維人員各司其職，各有壹套領域的工具和語言。時間長了，容易形成孤島，導致跨職能溝通困難，效率低下。這也是為什麽現在流行的敏捷開發和DevOps都強調溝通(前者是配合Biz和Dev，後者是配合Dev和Ops)，而經典的DDD領域驅動設計也提倡“統壹語言”，減少業務和技術人員的溝通不壹致。
請點擊輸入圖片說明。
有了低代碼，這種情況將得到根本改善:上述所有角色都可以在同壹個低代碼開發平臺上緊密合作(甚至是同壹個人)。這種全新的合作模式不僅打破了功能軸，還通過統壹的可視化語言和單壹的應用表示(頁面/數據/邏輯)，輕松對齊項目各方對應用形式和項目進度的理解，實現了更極致的敏捷開發模式，在傳統DevOps的基礎上更進壹步。
統壹開發平臺下的聚合效應
低代碼試圖將所有與應用開發相關的活動融合在同壹個平臺上，這將產生更多的聚合效應和規模效益:
人員聚合:除了上壹點提到的各個職能角色的緊密配合，人員聚合到壹個統壹的低代碼開發平臺，還可以促進整個項目流程的標準化、規範化和統壹化。
應用聚合:壹方面，新應用的架構設計、資產重用和相互調用變得更加容易；另壹方面，各應用的數據天然互通，平臺外的數據也可以通過集成能力打通，徹底消除企業的數據孤島問題。
生態聚合:當低代碼開發平臺聚合了足夠多的開發者和應用，就會形成壹個龐大的、互聯的、富有想象力的生態系統，徹底釋放低代碼的價值。