風口上的低程式碼：我們看到了這些變化與趨勢

在企業服務領域，今年低程式碼的概念非常火爆，最直觀的感受是，從前這類分享都是幾十人討論的小沙龍。今年各種數百人的峰會和專題會，都在大範圍地討論。而入場低程式碼也不再是創企的專利，大廠們也進入了搶灘的局面。騰訊在今年一月推出了微搭低程式碼的開發平臺，阿里差不多也在這個時間段釋出了“釘釘宜搭”低程式碼開發工具，而華為雲在2020年就釋出了低程式碼的開發平臺ROMA AppCube。國內的簡道雲、氚雲、輕流、易鯨雲等低程式碼企業也先後獲得了融資。

低程式碼的概念興起是在2014年，由研究機構Forrester提出，經過近幾年的發展，在國外已經有相對成熟的商業模式了。國內基本上是從2018年開始，討論的聲音多了起來，不過在這其中也有不少質疑的聲音，什麼“簡易低智”、“新瓶舊酒”、貼了標籤的“外包公司”等，經過三年時間的發酵，低程式碼搖身一變又成為企業不能錯過的風口，討論的聲音參與的企業越來越多。

據Gartner機構的預測，到2025年，企業70%的新應用將會透過低程式碼或者無程式碼技術開發，這將加快低程式碼市場的全面爆發。而另外一家研究機構海比研究院資料顯示，2020年，中國低市場規模達19億元，而到2024年，低程式碼市場將達到百億量級。

低程式碼快速發展的背後，源自於企業不斷增加的數字化轉型需求。企業需要簡化一些正規化化流程以及重複性工作，再加上疫情對企業線上化、數字化需求的加速，企業的內外系統在這個大的環境中需要迭代響應，跟隨潮流變化，低程式碼開始被企業接受。

低程式碼從各種質疑到成為企業數字化改造的選擇之一，不僅僅是身份發生了變化，在這背後，更為明顯的是低程式碼在這幾年的炒作與迭代中有了一些新的變化，而未來的可能性與趨勢也值得討論與關注。

向整合化平臺化演進

低程式碼平臺近兩年的變化，最明顯的是能力邊界的擴充。低程式碼是在各種元件和模組實現無程式碼化的基礎上發展起來的，早期的應用主要圍繞資料庫管理、報表管理等單點能力突破。隨著近兩年的探索與迭代，產品架構與設計能力的提升，低程式碼由元件、模組的無程式碼化向整合的平臺形式轉變。

之前，低程式碼更多作為工具幫助研發人員降低軟體開發過程中部分模組的重複工作，隨著可複用模組增加和雲端計算、微服務架構等技術的發展，透過平臺架構設計和引擎的開發不僅為IT人員減少了開發中重複造輪子的境況，也為業務線上沒有IT技術能力的員工提供開發應用的能力服務。隨著低程式碼服務在向各類細分行業的深入發展，其可擴充性和靈活度也得到了提升，複雜度、靈活度更高，能夠支援廣泛場景的複雜應用開發，自定義的能力與品類完整度也不斷升級。

比如在一些數字能力更新較慢的研究院所，雖然擁有自己研發的資訊平臺，但大多數專案依然習慣紙質管理，資料處理與資料儲存是這類院所主要的困擾。在選擇了低程式碼平臺進行資料錄入後，可以實現資料處理效率的升級和資料自動備份的能力，節省了大量人工成本的投入。

對於一些業務流程較複雜的企業，使用低程式碼平臺的流程功能，可針對性的設計符合企業特色的管理應用，將不同業務線的任務、人串聯起來，業務流程視覺化、業務負責人視覺化，基於透明的業務，業務與人、人與人的協作更加高效，節約業務流程的時間、管理成本。

對於不懂開發工作的人來說，可以基於圖形化介面，透過拖拉拽、模板元件呼叫等方式完成軟體應用構建，只要對管理或者業務的應用場景有一定的理解，就可以開發應用。曾經的資訊孤島現象屢見不鮮，現如今低程式碼和雲端計算的結合可以打破應用、企業、開發者之間的一些低效協作現象。透過可配置、可調整的工具，把企業的開發效率提升數倍甚至10倍以上。低程式碼也從元件工具的單點能力身份朝著整合化、平臺化的方向演進，來快速解決企業多元化需求。

當然低程式碼的能力也不是沒有邊界，發展的過程中仍然存在許多需要解決的問題。

低程式碼還需要解決哪些問題?

目前低程式碼主要的發展路徑有兩種模式，一種是基於表單引擎驅動的方式，一種是基於aPaaS平臺的模式，兩種低程式碼平臺的發展模式受限於模板、生態、可擴充套件性等因素，都不適合用來從頭開始構建厚重的企業核心數字化系統。這也是低程式碼平臺的能力邊界，除了自身邊界帶來的限制外，在低程式碼平臺的發展過程中，仍然存在不少要解決的難題。

1.市場教育。對於大型企業來說如何讓原本關注具體場景SaaS產品的使用者群體轉而關注能力更通用的低程式碼平臺，是所有從業者需要面臨的問題。引入低程式碼會改變一些企業的現有工作流程，對於一些企業來說阻力可能會較大。

2.需求匹配。市場教育的難關過了，對積極擁抱變化的企業來說，低程式碼廠商需要升級多維度的功能，匹配使用者的各類細分需求。對於中小型企業來說，每家的需求與痛點不同，比如政府、金融等一些對資訊保安看重的企業會在意私有化部署的能力，一些企業會看重低程式碼平臺產品價效比與功能的匹配。這些不同的訴求下，低程式碼平臺需要將功能的豐富與價效比等維度進行不斷迭代。

3.底層架構模型完善。對於企業使用者來說使用的傳統DevOps流程，低程式碼的一站式應用會對一些傳統DevOps流程及規範形成挑戰。低程式碼產品相關應用主要涉及到各種引擎、資料庫等中介軟體，底層架構需要更加靈活的微服務架構，使得低程式碼可以更好地完成二次開發和應用擴充。

4.職業角色的重新構建。對於低程式碼服務的管理人員來說，需要立足於業務，具備較高的抽象思維能力，能夠將業務場景工具化。對於使用低程式碼平臺的人來說，使用也會有對技術能力的需求。

雖然，當前整個低程式碼行業處於初始發展的階段，要面對與解決的問題不少，但是以低程式碼技術重構數字化業務的廠商必須提前看到未來在低程式碼市場層面的競爭，才有存活的可能。

低程式碼的終點站

從IT從業者的角度來看，程式碼一定會越寫越少。低程式碼是整個軟體開發行業的大趨勢和方向。從企業的數字化轉型的訴求角度來看，低程式碼也給企業緩解人才與成本的痛點。在價值升級的道路中，依據低程式碼的能力與行業特點，其未來也有三個可能的發展趨勢。

首先從低程式碼的發展歷程上來看，我們會發現，低程式碼的能力是從模組和元件發展起來的，早期是資料庫、表單等業務的管理。而現在低程式碼有一個很明顯的發展趨勢，由元件式單點能力的覆蓋突破向整合式的平臺模式發展。

而在大範圍的普及過程中，也會走向更加垂直細分的領域，面對千千萬萬的個性化需求，低程式碼的產品自定義能力也將是廠商未來重點發力的方向。而這也是廠商不斷提升平臺產品豐富度、完整度和競爭力的訴求與方向。

其次是低程式碼平臺在AI、物聯網等前沿技術的普及與應用過程中，也會有更多泛自動化、智慧化的變化。比如AI能力則可以提供OCR、NLP等工具輔助低程式碼平臺使用者進行商業決策，實現為使用者提供一體化服務的能力。

最後是低程式碼生態的構建。雖然目前是低程式碼平臺發展的初期，隨著市場教育的普及以及行業的廣泛運用，產品能力強的通用性廠商會優先跑出來，市場也會改變目前分散的情形，集中度大幅提升。低程式碼的產業生態模式也會在市場成熟的過程中建立，生態模式的建設會連線行業內的各路玩家，在互利互通的生態圈資源裡，大家各顯神通與價值。

在討論低程式碼的未來時，我們還需要在腦中設定其能力的邊界，低程式碼並不是萬金油，什麼需求都可以滿足。對於一些介面效果要求較高、演算法複雜、高效能複雜系統架構、要求較高的底層開發等，都不適合使用低程式碼。這部分要求較高的能力還是需要程式設計師來做，因此程式設計師也不用擔心低程式碼會搶走飯碗的情形。

關於低程式碼的能力邊界有個很好的比喻：低程式碼更適合做企業數字化建設當中“最後一公里”的事情，基於數字化系統構建創新類應用、運營類應用。這個比喻也很能明確的顯示低程式碼的能力圈範圍。

在企業全面擁抱數字化的程式中，不斷簡化正規化化流程、減少重複性工作，是數字化時代各行各業變革的核心訴求，這也是廠商們需要思考和賦能的價值趨勢，想要抓住價值增長的趨勢，除了核心產品的創新外，也需要最佳化企業業務發展和服務能力。對於數量眾多的中小企業來說，在自身IT能力的限制中，如何將外部的服務能力和自家的IT系統融合，保障企業數字化程式的價值賦能，是其接下來需要思考的方向。在這個方向的演進中，也會有低程式碼的一方天地。