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