低代碼開發是新瓶裝老酒嗎?
編輯導語:近幾年來,低代碼開發的概念也十分火熱,某種程度上,低代碼開發可以提升企業的開發效率,推動企業的數字化轉型,而這也是低代碼開發火起來的原因之一。本篇文章里,作者就對低代碼開發的發展做了全面解讀,一起來看看吧。
2021年,“低代碼”接力“中臺”燃起了熊熊之火,引發眾多業內人士論戰。其中有兩種極端的觀念,一種是“低端炒作”、“無用玩具”、“行業毒瘤”,另外一種是“顛覆行業”、“取代程序員”。
不管怎么說,低代碼現在已經被推向時代變革的大潮,成了我們數字化轉型過程中張口閉口的熱詞,它火熱的背后的動因是什么呢?它是新瓶裝舊酒嗎?它到底是行業毒瘤還是顛覆革命?
讓我們先來看看百度百科對低代碼的定義:
低代碼(Low Code)是一種可視化的應用開發方法,用較少的代碼、以較快的速度來交付應用程序,將程序員不想開發的代碼做到自動化,稱之為低代碼。低代碼是一組數字技術工具平臺,基于圖形化拖拽、參數化配置等更為高效的方式,實現快速構建、數據編排、連接生態、中臺服務。通過少量代碼或不用代碼實現數字化轉型中的場景應用創新。
——百度百科
一、低代碼的發展歷程
其實低代碼不是一個新概念,早在上世紀80年代,它的名字是“可視化編程”,指的是用很少或幾乎不寫代碼快速開發應用,并快速配置和部署的一種技術和工具。
推動現代低代碼開發模式發展的我認為是SaaS應用的發展,具有標志意義的就是2007年Salesforce面向開發者推出的Force.com應用開發平臺,第一次將低代碼應用到SaaS應用中(下文中會分析SaaS推送低代碼開發發展的原因)。
2014年,研究咨詢機構Forrester首次提出了“低代碼/零代碼”的概念,隨后在2018年Gartner又提出了aPaaS,和當下的低代碼/零代碼概念更為接近。從2018年開始,低代碼相關的廠商和應用如雨后春筍一般爆發,2020年繼中臺概念后被稱為低代碼元年。
但我們從上面的發展歷程圖上也能明顯的看出,其實從2014年(甚至追溯到2007年)到2018年這個時期,低代碼發展好像進入了一個空白期,為什么會出現這樣的情況呢?其實我們從國內的SaaS應用的發展也可以窺見端倪。
Salesforce開啟了SaaS模式之后,21世紀初SaaS模式還處市場探索的萌芽時期,直到2014-2018年才進入了快速發展期。SaaS爆發的初期,更多還是以標準化產品為主,服務的都是小微型客戶。所以這一時期SaaS對低代碼開發還沒有推動的動力。
二、推進低代碼發展的幾個因素
1. 從SaaS應用的能力進化看低代碼發展
在沒有SaaS模式之前,傳統的信息化都是通過購買或者開發部署獨立的私有化的信息產品為主,在這種傳統模式下,就造成了幾個問題:
- 對客戶來說,軟件的成本太高,少則幾萬,動輒上百萬、上千萬。而且成本高也體現在個性化需求開發的時候,而且一旦定制,就很難再升級。
- 對廠商來說,落地實施的成本很高,產品版本分化嚴重,后期維護成本很高,服務能力降低。新的功能研發上線,無法對老客戶實行二次銷售,客戶體驗差。
所以,對于很多中小型企業來說,因為SaaS產品的出現,也解決了初期軟件投入成本過高問題,同時不需要招聘太多專業的信息技術人員維護,SaaS模式逐步被接受。
但是SaaS的發展必然也面臨著客戶越來越多導致需求個性化的問題,SaaS的復雜性越來越大,發展的早期如何解決?
- 拒絕個性化,只做標準服務。但這種方式可以應付小微客戶,但是一旦有一定規模的客戶,不可避免的存在個性化定制,拒絕個性化,就是拒絕機會,無疑自找思路。
- 在產品上增加定制開發功能。當你無法把各個客戶的需求進行統一抽象,創建個性化功能模塊就是應對個性化開發之道。但是這種做法讓你的產品和代碼變成了一個大泥球,給未來的開發維護帶來巨大的災難。
- 為每個客戶創建分支版本。這個做法和傳統的軟件交付模式其實沒什么差別,只是接管了本來屬于甲方的運維,當分化的版本越來越多,版本維護和運維將是高昂的成本。
以上的做法其實是把傳統軟件開發的模式引入到SaaS應用中,實際上依然沒有從本質上,底層上解決問題。Salesforce其實給我們指明了道路——SaaS應用的PaaS化。通過提供具備開發能力的PaaS平臺,為SaaS應用提供定制開發能力。為了降低在PaaS平臺上開發的難度和工作量,于是低代碼開發平臺也就應運而生。
2. 從企業數字化轉型需求看低代碼發展
數字經濟下產品更新換代速度加快,市場需求更迭同步提速,企業需要不斷提升軟件開發效率和市場響應速度的產品。但傳統的開發模式對企業數字化轉型提出巨大的挑戰,導致出現一些問題和痛點,具體分析如下:
- 從滿足需求角度,資源缺口導致長尾需求無法滿足;
- 從降低成本角度,軟件成本高導致全面數字化推動力不足;
- 從改善架構角度,傳統系統架構可擴展性及集成度不高;
- 從孵化創新角度,重復建設、標準不統一、業務協同差導致對新業務的支持度不高。
而低代碼開發像拖拉拽的可視化開發方式,樂高式的應用搭建,共生的一體化平臺等特點能在一定程度上解決企業數字化轉型的這些需求和痛點。
3. 從技術和企業數智化演進看低代碼發展
從企業數智化的發展經歷了幾個階段(如上圖),每個階段都伴隨著巨大的信息技術的變革,在前兩個階段,開發工具的推動起到了很大的作用,開發語言的高級特性及開發工具的能力提升,讓工程師的開發效率獲得提高。而到了互聯網化的階段,云計算、虛擬化、容器化帶動了云端技術的巨大發展,特別是云原生技術的提出和發展,讓基于云端的開發發生了質的變化。
軟件開發技術發展的核心是讓技術實現更簡單這個核心原則始終沒有改變,而低代碼開發的目的也正好符合這個原則,所以低代碼開發模式得到推崇和發展也是情理之中。
三、低代碼產品的形態
現在市場上低代碼的產品琳瑯滿目,低代碼廠商也是百花齊放,按搭建應用時是否需要代碼可以將廣義低代碼產品分為狹義低代碼和零代碼兩種,二者均可通過可視化界面,對封裝好的代碼模塊進行拖拉拽來完成應用搭建。
其中低代碼主要服務關注業務邏輯的開發部門,需要少量代碼進行模塊銜接或功能 拓展;零代碼更強調低代碼的低門檻,僅需理順業務邏輯即可快速搭建流程管理、表單等輕量級應用。
整體上看,低代碼產品的函數與系統解耦,在少量代碼的支持下應用場景較廣,而零代碼輕量便捷,搭建速度快,賦予業務部門更多自主權。零代碼使用門檻低,但支持的場景有限,而低代碼可搭建復雜度較高的應用,這也是我們主要深入了解低代碼的原因。
按照低代碼產品的底層驅動技術可劃分為表單驅動、邏輯驅動和數據驅動三類。
- 表單驅動直接關注業務場景,以數據表為 核心、以工作流為媒介構建應用。
- 模型驅動從業務場景中抽象出模型構建頁面和業務流,其應用場景更加復雜且廣泛。
- 數據驅動在模型驅動的基礎上深度挖掘數據價值,將從互聯網及其他軟件收集來的數據進行匯總和整理,運用新技術和算法訓練擬合成自動化決策模型。
整體上看,低代碼正從基礎表單向數據驅動遞進,其功能性逐漸提升,覆蓋更多業務場景。
從使用者需求的角度來看,低/無代碼平臺可劃分為四大類型:場景應用型、產品研發型、平臺生態型和技術賦能型。
根據海比研究院調研數據,目前市場上共有低/無代碼廠商74家。從各類型平臺商的數量分布來看,場景應用型數量最多占比達59.5%,說明終端應用的客戶是低代碼的只要使用者,其次是產品研發型、平臺生態型和技術賦能型。
從各類型平臺商的年均收入規模來看,技術賦能型收入平均年收入最高,其次是平臺生態型,再次是產品研發型和場景應用型。綜合當前平臺生態型和技術賦能型數量不多但盈利能力較強,預計是未來廠商重點發展方向。
四、低代碼的能力體現
從行業這么多低代碼產品的功能來看,低代碼開發平臺的核心能力包括:
- 易用性。在不寫代碼的情況下能夠完成的功能多寡是決定平臺是否容易被接受的重要指標;
- 用戶體驗。該指標能夠決定最終用戶對開發者的好評程度;
- 數據建模和管理。應用復雜度越高,系統集成的要求越高,這個能力就越關鍵;
- 流程和業務邏輯。決定了低代碼支持的應用的寬度范圍;
- 接口和集成。低代碼不要為企業再造一個個數據孤島;
- 軟件開發周期支持。除了開發和交付,還需要包含設計、反饋、測試、運維等多個環節;
- 服務質量。所開發應用的故障率、穩定性,以及技術支持能力;
- 安全和合規。需要在部署方式、系統安全機制和權限管理和控制功能等層面提供全方位支持;
- 平臺生態。獨木不成林,需要引入更多開發者,提供更豐富的解決方案,更好的賦能應用開發者。
和傳統的軟件開發的模式相比,低代碼開發的流程極大的縮減,需要的崗位和人員也極大的減少,這就帶來了兩大優勢:
1)提高開發效率和降低成本
- 圖形化開發,大幅降低工作量;
- 有效規避代碼本身的bug問題;
- 開發完成一鍵部署多個環境;
- 降低對開發者的要求,降低成本。
2)企業數字化轉型的有力工具
- 降低應用開發的準入門檻;
- 有助于打破信息系統的孤島;
- 加速各種能力服務化的進程。
五、認識低代碼的價值,也看清它的短板
任何新鮮事物的發展和火熱,我們都要先積極的擁抱它,只要它能幫助我們解決一定的問題,那么它就是有價值的。所以梳理一下低代碼開發的一些價值體現:
- 快速。快速開發、快速反饋、快速調整,溝通過程中即可所見即所得開發;
- 低成本。降低技術門檻,不需要專業技術人才就可以開發;
- 個性化支持。通過靈活的組件、模塊來解決各種個性化需求,而不需要去修改代碼;
- 易維護。采用組件化、在線組裝的方式,代碼侵入少,更容易調整;
- 保護隱私。減輕對外部廠商的依賴,保護企業信息的隱私;
- 貼近業務價值。專注于業務功能開發,甚至業務人員可以深度參與。
雖然低代碼開發有很高的價值,但低代碼并不是萬能的,它也有自己不擅長的領域,比如:
- 算法和數據結構復雜的應用。低代碼開發此類應用的成本不亞于直接寫代碼,甚至更高,無法發揮它的優勢;
- 對界面要求特別高的應用。低代碼平臺可不擅長做酷炫的界面,所以游戲、動畫相關的應用并不適合;
- 超高流量互聯網的應用。低代碼開發中的性能大部分損失在配置解析,腳本解析上,所以對于性能有著非常高的追求的互聯網應用并不適合;
- 分析和智能化的應用。分析有BI工具,智能化應用更側重底層數據計算,這類的應用應該交給特定的專有工具實現;
- 系統軟件、科學計算等應用。對于功能擴展性需求很弱,沒有可復用可抽象性,且底層計算很多,用低代碼開發并不見得有優勢,甚至不可行。
所以,低代碼不是銀彈,不要妄想通過引入低代碼來解決你所有問題,它能解決的問題范圍有限,用對地方真正有效解決問題才是正道。它也不是程序員終結者,它只是數字化轉型應用開發中的一個補充,應用開發的主戰場還是coding,coding,coding。它淘汰的只是會CRUD的偽程序員。寫好代碼解決問題才是我們立足的根本。
六、我為什么要搞低代碼?
其實,十年前我在做工作流引擎和系統的時候,我認為就已經在從事低代碼相關能力的開發和實踐了,雖然那時候前后端的技術體系并不是特別的完善,而且自己并不擅長前端頁面的構建,但是也基本上實現了拖拉拽的(雖然相比現在的界面過于簡陋)自定義的流程模型,可視化的自定義表單設計,以及基本的權限控制和腳本植入。
前年我又在團隊中提出了低代碼能力的建設,設計了以表單驅動為核心的低代碼開發模塊作為我們技術平臺和中臺能力的一種補充。當時出于對低代碼的幾點認知:
1)要解決什么問題?
① 隨訪產品中自定義隨訪的表單。不同的臨床領域、不同的客戶,他的隨訪表單是不一樣的,這個是很難在研發時固化到系統中的。
② 專病健康檔案的設計和展示。不同的病種,不同的客戶,在不同的應用下對于健康檔案的數據結構,展示的屬性是不一樣的,需要實現其靈活的擴展。
從應用場景上來說,主要是解決產品落地實施項目的時候解決個性化需求,以及產品使用過程中不斷擴展的需求。
2)使用的對象是誰?
首先,研發人員不是我設計低代碼開發模塊的目標用戶群體,因為對于很多研發人員來說,寫原生代碼才能真正的體現自己的價值,另外即使需要快速開發,也會優先使用代碼生成工具生成原生代碼,并在此基礎上進行邏輯編寫。
那么低代碼開發面對的目標人群到底是誰呢?我們的定義是項目實施工程師,部分產品經理或者醫學支持人員。而零代碼的功能可以開放給客戶使用,以幫助他們自助解決部分個性化問題。
低代碼開發雖然不是一個新鮮的概念,但是由于科技的發展,企業發展訴求的變化,特別在企業數字化轉型的大趨勢面前,它脫胎換骨,有了更加高級的形態,這是時代的產物,這是趨勢的結果。
就像現在的特斯拉相比于上個世紀初的奔馳,今天的智能手機相比于十幾年前的諾基亞功能手機,同樣都是汽車、手機,但是它們所承載的作用,以及它們對于我們的意義都發生了巨大的變化。所以,不論是新瓶老酒還是老瓶新酒,只要能解決我們當前的問題,能夠體現它的價值,喝起來都是一樣的甘醇。
#專欄作家#
菜根老譚,微信公眾號:CGLT_TAN,人人都是產品經理專欄作家。經歷程序員、技術Leader、產品經理、研發Leader等多種崗位?,F負責某科技公司整體產品研發,擅長企業IT架構及互聯網產品架構。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
文章低代碼產品形態那章節,關于低代碼類型中場景應用類型的數據圖文不一致。
有沒有什么好的低代碼開發平臺?
關注公眾號:數智化解決方案,回復:低代碼
excel 都學不會,怎么用低代碼?
低代碼的再次爆火或許這是一種炒作,低代碼是一種無用的玩具
“不論是新瓶老酒還是老瓶新酒,只要能解決我們當前的問題,能夠體現它的價值,喝起來都是一樣的甘醇?!焙苜澩瑍
感謝支持??梢约游夜娞?,一起交流討論
低代碼開發可以提升企業的開發效率,推動企業的數字化轉型。
低代碼并不能代替程序員,因為它解決的只是一些比較簡單的問題。更復雜的設計還需要人工