從快速開發(fā)平臺到低代碼開發(fā)平臺(從快速開發(fā)平臺到低代碼開發(fā)平臺需要多久)
作者:人月神話,新浪博客同名
簡介:多年SOA規(guī)劃建設,私有云PaaS平臺架構設計經驗,長期從事一線項目實踐
今天準備談下快速開發(fā)平臺和低代碼開發(fā)平臺方面的內容。
快速開發(fā)平臺本身的欠缺點
對于快速開發(fā)平臺在10年前我關注的比較多,當時也是屬于快速開發(fā)平臺的狂熱者,也試圖去構建一個完整的包括了對象建模,數據建模,流程建模,規(guī)則建模,界面建模的完整快速開發(fā)平臺。但是最近幾年這方面的關注比較少,只在16年對開源的基于元數據驅動的EOVA平臺進行了簡單試用,在去年對JEPaas平臺進行了簡單試用。
當然就公司來說本身也有一個積累了很多年的技術平臺,要上升到產品化的快速開發(fā)平臺還有一定距離,但是也足夠我們日常項目使用。其中最重要的就是流程引擎和4A,還有就是共性的技術組件的抽取和積累。
這幾年沒有關注快速開發(fā)平臺,其原因究竟在哪里?實際上最主要的原因包括二個方面:
- 快速開發(fā)平臺本身往往是一個封閉的系統(tǒng),擴展維護存疑,同時該技術資產不受企業(yè)控制。
- 面對一些特殊的和復雜的業(yè)務場景需求往往難以滿足,同時也沒有開放擴展類接口能力。
特別是對于第2個問題,即使你滿足了99%的功能需求可靈活配置,但是關鍵需求的1%無法滿足,整個快速開發(fā)平臺是黑盒你無法去定制和擴展,同時平臺提供商也不幫你定制開發(fā),那么這個業(yè)務系統(tǒng)就很難最終交付給客戶使用。
我們經常會說軟件開發(fā)商有時候會綁架客戶,那么同樣道理,這類的快速開發(fā)平臺能力提供商往往就容易綁架軟件開發(fā)商。軟件開發(fā)商用平臺朝客戶交付了軟件產品,但是最終這個軟件產品的可運維屬性并不真正掌控在軟件開發(fā)商手里面,這就是最要命的一點。
也正是這個原因我們也看到,往往是有一個小規(guī)模的軟件開發(fā)隊伍的甲方企業(yè)往往容易選擇這類快速軟件開發(fā)平臺,即自己定制和快速開發(fā)后自己用,平臺提供商提供二次服務能力,減少了軟件開發(fā)商這個環(huán)節(jié)。
再其次,一個軟件企業(yè)的開發(fā)團隊本身也不愿意采用這種平臺。
團隊人員往往喜歡學習和嘗試各種開源技術和新框架,希望自己在開發(fā)過程中鍛煉自己各方面的技術能力儲備提升自我價值,這種技術能力儲備本身是適配所有的軟件開發(fā)企業(yè)的。
而對于這種快速開發(fā)平臺本身,開發(fā)人員更多是進行簡單的配置和SQL編寫,很多技術細節(jié)已經封裝在底層,開發(fā)人員想要提升技術能力很難。
如果要給剛畢業(yè)的一開始就接觸這種平臺,即使你平臺用的再熟,脫離平臺你發(fā)現連基本的簡單功能都做不出來。對于Java的常用開發(fā)框架,開源組件,三層架構,數據庫建模等更是一竅不通,這也是大部分從事軟件開發(fā)人員不愿意的事情。
快速開發(fā)平臺的優(yōu)勢在哪里?
而今天我為何還要再談快速開發(fā)平臺?
主要原因還是這幾年快速開發(fā)平臺本身也在快速的發(fā)展,一個快速開發(fā)平臺只要應用的企業(yè)和團隊多了,那么就更加容易在實踐過程中不斷的將個性化需求抽象為共性需求融入到快速開發(fā)平臺里面,這個本身有一個過程,積累的越久,快速開發(fā)平臺的能力往往也就越強大。
而當前來說,一個好的快速開發(fā)平臺往往可以解決90%以上的業(yè)務需求功能實現,而個性化或定制的充分提供開放接口給你自己去處理。那么這種開發(fā)平臺本身是有價值的,可以真正做到快速的功能交付和對需求的敏捷響應能力。同時一個功能開發(fā)往往還同時適配桌面和手機端,更是減少了重復開發(fā)和定制的工作量。
而對于開發(fā)人員來說,很多開發(fā)往往做的實際就是開發(fā)平臺的活,簡單的增刪改查功能,而且做的質量還沒有開放平臺好,要價和成本還不低,速度也慢。這類開發(fā)人員往往最終一定會被取代掉,這也是我原來就強調過的對于軟件開發(fā)人員的薪酬一定會出現兩級分化。高的會很高,而低的也會更低,不會出現類似前兩年隨便一個IT培訓班出來的人員就能夠拿高工資的現象。
由于快速開發(fā)平臺本身的交付周期很短,可以更加方便我們快速的形成可用的產品原型給客戶演示和試用,并快速的進行迭代變更和優(yōu)化。這可以很好的解決傳統(tǒng)模式下靜態(tài)原型或Axure原型本身交互和數據上面的弱項,真正讓用戶邊使用邊優(yōu)化。
如果一個業(yè)務系統(tǒng)真正發(fā)揮作用了,業(yè)務和數據量也都呈現明顯的增長趨勢,我們大可以重新規(guī)劃完全重做并脫離快速開發(fā)平臺,而采用快速開發(fā)平臺則是擁有了最小的試錯成本。
最近幾周,自己又重新搜索了下當前提供商用的快速開發(fā)平臺的公司,對于幾個產品也初步進行了演示環(huán)境的使用,確實了比前面幾年有了很大進步,至少我們常用的功能實現都能夠很輕松的配置出來。幾家的比較下來,自己比較推薦如下這家的快速開發(fā)平臺,也準備在后面深度試用下。
http://www.jepaas.com/
對于這個平臺我自己做了簡單的試用,大家也可以試用下,簡單總結就是對于快速開發(fā)平臺仍然任重道遠,遠遠沒有達到我們期望的一個程度。
我們熟悉的軟件項目也,平常看似單純而率直,但很可能一轉眼就變成一只時程延誤、預算超支、產品充滿瑕疵的怪獸,所以,我們聽到了絕望的呼喚,渴望有一種銀彈,能夠有效降低軟件開發(fā)的成本,就跟電腦硬件成本能快速下降一樣。但是,我們預見,從當前開始的十年之內,將不會看到任何銀彈,無論是在技術上或管理上,都不會有任何單一的重大突破,能夠保證在生產力、可靠度或簡潔性上獲得改善,甚至,連一個數量級的改善都不會有。-《沒有銀彈》
如果最近又接一些小項目,也打算用這個平臺做下嘗試,看下實際的效果如何。而對于快速開發(fā)平臺而言,一個好的快速開發(fā)平臺必須具備的一些關鍵能力如下。
- 高度靈活,可配置的流程引擎能力,4A能力,核心是用戶,組織,資源,權限。
- 報表平臺能力
- 靈活的頁面表單可視化設計和配置能力
- 業(yè)務規(guī)則和邏輯的可配置能力
- 數據庫sql的靈活配置能力
- 同時對桌面端和移動端的雙向生成和交付能力
- 門戶的可配置化和定制能力
- 日志監(jiān)控和運維管理能力,封閉平臺應該提供的問題排查能力
- 靈活開放的二次開發(fā)接口能力
如果從甲方角度思考,還有一點就是可可以完整源代碼導出并交付的能力,方便后續(xù)甲方接手管理和運維。一個好的快速開發(fā)平臺一定不能搞來自我封閉,導致后續(xù)客戶無法自行維護,也無法進行能力遷移,這些問題點都必須避免。
從快速開發(fā)平臺到低代碼平臺
最近我差不多花了兩到三天的時間進一步研究了下網上的低代碼開發(fā)平臺,也就是原來我們經常說的快速開發(fā)平臺。研究這個的一個主要原因就是我們看到在新的微服務,DevOps,ServerLess技術,前端新技術的發(fā)展趨勢下,低代碼開發(fā)在時隔多年后被再一次的提起。
在微服務和云原生解決方案不斷發(fā)展的情況下,我們看到當前的云服務已經從最傳統(tǒng)的彈性計算和存儲能力,提升到了我們常說的PaaS平臺層,即提供更多的類似消息,緩存,數據庫,中間件,安全,大數據平臺等平臺層服務能力。
有了這些共性技術服務能力后,應用開發(fā)就能夠基于這些共性技術服務能力,應用開發(fā)能夠更加只關注業(yè)務流程和業(yè)務邏輯的實現,再加上當前主流的微服務 DevOps 容器調度的云原生解決方案思想。即我們當前的應用開發(fā)更加敏捷和高效,能夠快速的響應業(yè)務的需求。
那么我們接著能夠考慮的就是在平臺層足夠強大后,我們的開發(fā)能否進一步更加簡化,能夠實現無代碼或少量代碼就能夠完成一個功能的開發(fā)和朝云端的部署上線。
比如我們現在看到的亞馬遜的公有云提供的ServerLess就是一個典型的場景。你只需要寫少量的配置文件或函數方法,就能夠完成一個類似網頁爬蟲,信息搜索,圖片存儲等互聯網功能。
第一:傳統(tǒng)的快速開發(fā)平臺
為了搞清楚低代碼開發(fā),我們可以看下在原來我們經常提到的快速開發(fā)平臺。對于原來我們談的快速開發(fā)平臺,我想可以初步分為兩種典型的類型。
- 面向業(yè)務人員:完全不需要開發(fā)經驗,不用接觸代碼。典型是類似各種BPM可定制產品。
- 面向技術人員:提供快速開發(fā)平臺和工具,比如代碼自動生成,功能大部分可配置 腳本模式。
對于面向業(yè)務人員方式的平臺往往就是一個高度靈活的空平臺,所有的對象,數據,流程,規(guī)則,權限等你都可以隨意的配置和定制。類似各類BPM產品,但是實際上可以看到這類產品無法開發(fā)規(guī)則業(yè)務復雜的系統(tǒng)。
對于面向技術人員的快速開發(fā)平臺,類似我們常說的普元,JeeSite, JEPaaS,起步科技的PaaS平臺等都屬于這種類型。但是這種類型的平臺本身又細分為了兩種,一種是僅僅輔助開發(fā)和代碼生成,即所有的開發(fā)內容都生成代碼,脫離開發(fā)平臺環(huán)境也能夠成功運行;還有一種就是強綁定,平臺很大內容不生成代碼,對你黑盒,無法脫離環(huán)境運行。
對于起步JuStep的快速開發(fā)平臺和PaaS云,我沒有進行試用,但是在10年前推出的快速開發(fā)平臺我試用過,這個企業(yè)能夠這么長周期的生存下來產品應該自有一定的優(yōu)勢和能力。特別是現在提出的快速開發(fā)平臺和PaaS云 DevOps融合集成更是一個大趨勢。
即我們原來在談整個云原生解決方案的時候,里面有一個內容塊就是快速開發(fā)平臺和開發(fā)框架。
我原來比較強調技術開發(fā)類平臺是否提供源代碼,是否進行強綁定,但是最近思考了下這個反而不是重點,真正重要的還是這個平臺對各類場景,各類業(yè)務需求下的通用模式抽象能力,這個將直接影響到平臺本身的好壞。比如一個平臺本身黑盒無法擴展,但是你的業(yè)務場景又很難配置出來,那么整個平臺的可用性就大大的打折扣。
其次,對于一個快速開發(fā)平臺,我們可以有一個重要結論:你對不同業(yè)務,不同場景下的通用性適配能力越強大,那么你實際運行的黑盒代碼性能就越低。
也正是這個原因,我們看到很大快速開發(fā)平臺代碼臃腫,性能低下,你開發(fā)的時候速度倒是快了。但是后續(xù)系統(tǒng)的性能完全跟不上,也無法擴展,這些都是要命的問題。
第二:從傳統(tǒng)快速開發(fā)到低代碼開發(fā)平臺
為了進一步談我自己對低代碼開發(fā)平臺的理解,我先引用下網上對低代碼開發(fā)的一些定義和說明。
低代碼開發(fā)平臺是無需編碼(0代碼或無代碼)或通過少量代碼就可以快速生成應用程序的開發(fā)平臺。它的強大之處在于,允許終端用戶使用易于理解的可視化工具開發(fā)自己的應用程序,而不是傳統(tǒng)的編寫代碼方式。構建業(yè)務流程、邏輯和數據模型等所需的功能,必要時還可以添加自己的代碼。完成業(yè)務邏輯、功能構建后,即可一鍵交付應用并進行更新,自動跟蹤所有更改并處理數據庫腳本和部署流程,實現在 IOS,Android,Web 等多個平臺上的部署。
低代碼開發(fā)平臺(LCDP)英文全稱為Low-Code Development Platform,一個顯著的特點是,更多的人可以參與到應用程序開發(fā)當中,不僅是具有專業(yè)編程能力的程序員,非技術背景的業(yè)務人員同樣可以構建應用;對于大型企業(yè)來講,低代碼開發(fā)平臺還可以降低IT團隊培訓、技術部署的初始成本。
從這個定義上面我們可以找到一些關鍵點,簡單總結來說就是
- 少量代碼或者無代碼,業(yè)務人員也能參與
- 提供可視化,可配置的工具進行配置和建模
- 可同時發(fā)布到多個平臺或終端
- 提供和云端的持續(xù)集成和發(fā)布能力,可持續(xù)交付,即我們常說的DevOps
對于低代碼開發(fā)平臺和快速開發(fā)平臺區(qū)別,實際我想強調一個重點,我個人認為很重要,即:低代碼開發(fā)需要實現從最早的以數據庫對象建模方式轉變?yōu)榉栈7绞健?/strong>
即快速開發(fā)平臺提供的能力應該是各種技術服務和技術組件,我們前臺應用的構建能夠快速的使用和組裝這些能力服務,實現快速的可視化編排,這點大家也可以參考下JuStep快速平臺的思路。
由于我們自己沒有詳細試用,因此在這里不做評價。
傳統(tǒng)的快速開發(fā)平臺不論是表單或流程涉及,更多的還是圍繞數據庫為核心進行,建立的對象可以生成數據庫。相關的表單操作也圍繞數據庫進行。
而在低代碼開發(fā)時代,我個人更加推薦一個轉變,就是基于對象服務化的分層開發(fā)模式。這個本身也是更加貼近我當前中臺和微服務的構建思路。即你首先去構建你的對象并發(fā)布你的服務,然后再考慮如何基于這些發(fā)布的服務類構建上層的應用。即我們的開發(fā)過程橫向拆分為兩端。而中間基于服務進行松耦合連接。
即:微服務 服務 前端應用。
不是簡單的我們傳統(tǒng)應用拆分小了,而且我們的前端應用模塊,后端能力模塊也全部微服務化,形成我們當前說的平臺 中臺 前端應用的分層模式。
這種模式如果再和我們當前的DevOps和容器化技術結合,那么整個開發(fā)完成的應用就更加容易持續(xù)發(fā)布和交付,也更加容易在后續(xù)繼續(xù)彈性資源擴展和調度。
歡迎關注@人月聊IT 分享SOA,微服務,DevOps平臺規(guī)劃和建設。