作者：人月神話，新浪博客同名

簡介：多年SOA規(guī)劃建設(shè)，私有云PaaS平臺架構(gòu)設(shè)計經(jīng)驗，長期從事一線項目實踐

今天準(zhǔn)備談下快速開發(fā)平臺和低代碼開發(fā)平臺方面的內(nèi)容。

快速開發(fā)平臺本身的欠缺點

對于快速開發(fā)平臺在10年前我關(guān)注的比較多，當(dāng)時也是屬于快速開發(fā)平臺的狂熱者，也試圖去構(gòu)建一個完整的包括了對象建模，數(shù)據(jù)建模，流程建模，規(guī)則建模，界面建模的完整快速開發(fā)平臺。但是最近幾年這方面的關(guān)注比較少，只在16年對開源的基于元數(shù)據(jù)驅(qū)動的EOVA平臺進(jìn)行了簡單試用，在去年對JEPaas平臺進(jìn)行了簡單試用。

當(dāng)然就公司來說本身也有一個積累了很多年的技術(shù)平臺，要上升到產(chǎn)品化的快速開發(fā)平臺還有一定距離，但是也足夠我們?nèi)粘ｍ椖渴褂谩Ｆ渲凶钪匾木褪橇鞒桃婧?A，還有就是共性的技術(shù)組件的抽取和積累。

這幾年沒有關(guān)注快速開發(fā)平臺，其原因究竟在哪里？實際上最主要的原因包括二個方面：

• 快速開發(fā)平臺本身往往是一個封閉的系統(tǒng)，擴(kuò)展維護(hù)存疑，同時該技術(shù)資產(chǎn)不受企業(yè)控制。
• 面對一些特殊的和復(fù)雜的業(yè)務(wù)場景需求往往難以滿足，同時也沒有開放擴(kuò)展類接口能力。

特別是對于第2個問題，即使你滿足了99%的功能需求可靈活配置，但是關(guān)鍵需求的1%無法滿足，整個快速開發(fā)平臺是黑盒你無法去定制和擴(kuò)展，同時平臺提供商也不幫你定制開發(fā)，那么這個業(yè)務(wù)系統(tǒng)就很難最終交付給客戶使用。

我們經(jīng)常會說軟件開發(fā)商有時候會綁架客戶，那么同樣道理，這類的快速開發(fā)平臺能力提供商往往就容易綁架軟件開發(fā)商。軟件開發(fā)商用平臺朝客戶交付了軟件產(chǎn)品，但是最終這個軟件產(chǎn)品的可運維屬性并不真正掌控在軟件開發(fā)商手里面，這就是最要命的一點。

也正是這個原因我們也看到，往往是有一個小規(guī)模的軟件開發(fā)隊伍的甲方企業(yè)往往容易選擇這類快速軟件開發(fā)平臺，即自己定制和快速開發(fā)后自己用，平臺提供商提供二次服務(wù)能力，減少了軟件開發(fā)商這個環(huán)節(jié)。

再其次，一個軟件企業(yè)的開發(fā)團(tuán)隊本身也不愿意采用這種平臺。

團(tuán)隊人員往往喜歡學(xué)習(xí)和嘗試各種開源技術(shù)和新框架，希望自己在開發(fā)過程中鍛煉自己各方面的技術(shù)能力儲備提升自我價值，這種技術(shù)能力儲備本身是適配所有的軟件開發(fā)企業(yè)的。

而對于這種快速開發(fā)平臺本身，開發(fā)人員更多是進(jìn)行簡單的配置和SQL編寫，很多技術(shù)細(xì)節(jié)已經(jīng)封裝在底層，開發(fā)人員想要提升技術(shù)能力很難。

如果要給剛畢業(yè)的一開始就接觸這種平臺，即使你平臺用的再熟，脫離平臺你發(fā)現(xiàn)連基本的簡單功能都做不出來。對于Java的常用開發(fā)框架，開源組件，三層架構(gòu)，數(shù)據(jù)庫建模等更是一竅不通，這也是大部分從事軟件開發(fā)人員不愿意的事情。

快速開發(fā)平臺的優(yōu)勢在哪里？

而今天我為何還要再談快速開發(fā)平臺？

主要原因還是這幾年快速開發(fā)平臺本身也在快速的發(fā)展，一個快速開發(fā)平臺只要應(yīng)用的企業(yè)和團(tuán)隊多了，那么就更加容易在實踐過程中不斷的將個性化需求抽象為共性需求融入到快速開發(fā)平臺里面，這個本身有一個過程，積累的越久，快速開發(fā)平臺的能力往往也就越強(qiáng)大。

而當(dāng)前來說，一個好的快速開發(fā)平臺往往可以解決90%以上的業(yè)務(wù)需求功能實現(xiàn)，而個性化或定制的充分提供開放接口給你自己去處理。那么這種開發(fā)平臺本身是有價值的，可以真正做到快速的功能交付和對需求的敏捷響應(yīng)能力。同時一個功能開發(fā)往往還同時適配桌面和手機(jī)端，更是減少了重復(fù)開發(fā)和定制的工作量。

而對于開發(fā)人員來說，很多開發(fā)往往做的實際就是開發(fā)平臺的活，簡單的增刪改查功能，而且做的質(zhì)量還沒有開放平臺好，要價和成本還不低，速度也慢。這類開發(fā)人員往往最終一定會被取代掉，這也是我原來就強(qiáng)調(diào)過的對于軟件開發(fā)人員的薪酬一定會出現(xiàn)兩級分化。高的會很高，而低的也會更低，不會出現(xiàn)類似前兩年隨便一個IT培訓(xùn)班出來的人員就能夠拿高工資的現(xiàn)象。

由于快速開發(fā)平臺本身的交付周期很短，可以更加方便我們快速的形成可用的產(chǎn)品原型給客戶演示和試用，并快速的進(jìn)行迭代變更和優(yōu)化。這可以很好的解決傳統(tǒng)模式下靜態(tài)原型或Axure原型本身交互和數(shù)據(jù)上面的弱項，真正讓用戶邊使用邊優(yōu)化。

如果一個業(yè)務(wù)系統(tǒng)真正發(fā)揮作用了，業(yè)務(wù)和數(shù)據(jù)量也都呈現(xiàn)明顯的增長趨勢，我們大可以重新規(guī)劃完全重做并脫離快速開發(fā)平臺，而采用快速開發(fā)平臺則是擁有了最小的試錯成本。

最近幾周，自己又重新搜索了下當(dāng)前提供商用的快速開發(fā)平臺的公司，對于幾個產(chǎn)品也初步進(jìn)行了演示環(huán)境的使用，確實了比前面幾年有了很大進(jìn)步，至少我們常用的功能實現(xiàn)都能夠很輕松的配置出來。幾家的比較下來，自己比較推薦如下這家的快速開發(fā)平臺，也準(zhǔn)備在后面深度試用下。

http://www.jepaas.com/

對于這個平臺我自己做了簡單的試用，大家也可以試用下，簡單總結(jié)就是對于快速開發(fā)平臺仍然任重道遠(yuǎn)，遠(yuǎn)遠(yuǎn)沒有達(dá)到我們期望的一個程度。

我們熟悉的軟件項目也，平?？此茊渭兌手保芸赡芤晦D(zhuǎn)眼就變成一只時程延誤、預(yù)算超支、產(chǎn)品充滿瑕疵的怪獸，所以，我們聽到了絕望的呼喚，渴望有一種銀彈，能夠有效降低軟件開發(fā)的成本，就跟電腦硬件成本能快速下降一樣。但是，我們預(yù)見，從當(dāng)前開始的十年之內(nèi)，將不會看到任何銀彈，無論是在技術(shù)上或管理上，都不會有任何單一的重大突破，能夠保證在生產(chǎn)力、可靠度或簡潔性上獲得改善，甚至，連一個數(shù)量級的改善都不會有。-《沒有銀彈》

如果最近又接一些小項目，也打算用這個平臺做下嘗試，看下實際的效果如何。而對于快速開發(fā)平臺而言，一個好的快速開發(fā)平臺必須具備的一些關(guān)鍵能力如下。

1. 高度靈活，可配置的流程引擎能力，4A能力，核心是用戶，組織，資源，權(quán)限。
2. 報表平臺能力
3. 靈活的頁面表單可視化設(shè)計和配置能力
4. 業(yè)務(wù)規(guī)則和邏輯的可配置能力
5. 數(shù)據(jù)庫sql的靈活配置能力
6. 同時對桌面端和移動端的雙向生成和交付能力
7. 門戶的可配置化和定制能力
8. 日志監(jiān)控和運維管理能力，封閉平臺應(yīng)該提供的問題排查能力
9. 靈活開放的二次開發(fā)接口能力

如果從甲方角度思考，還有一點就是可可以完整源代碼導(dǎo)出并交付的能力，方便后續(xù)甲方接手管理和運維。一個好的快速開發(fā)平臺一定不能搞來自我封閉，導(dǎo)致后續(xù)客戶無法自行維護(hù)，也無法進(jìn)行能力遷移，這些問題點都必須避免。

從快速開發(fā)平臺到低代碼平臺

最近我差不多花了兩到三天的時間進(jìn)一步研究了下網(wǎng)上的低代碼開發(fā)平臺，也就是原來我們經(jīng)常說的快速開發(fā)平臺。研究這個的一個主要原因就是我們看到在新的微服務(wù)，DevOps，ServerLess技術(shù)，前端新技術(shù)的發(fā)展趨勢下，低代碼開發(fā)在時隔多年后被再一次的提起。

在微服務(wù)和云原生解決方案不斷發(fā)展的情況下，我們看到當(dāng)前的云服務(wù)已經(jīng)從最傳統(tǒng)的彈性計算和存儲能力，提升到了我們常說的PaaS平臺層，即提供更多的類似消息，緩存，數(shù)據(jù)庫，中間件，安全，大數(shù)據(jù)平臺等平臺層服務(wù)能力。

有了這些共性技術(shù)服務(wù)能力后，應(yīng)用開發(fā)就能夠基于這些共性技術(shù)服務(wù)能力，應(yīng)用開發(fā)能夠更加只關(guān)注業(yè)務(wù)流程和業(yè)務(wù)邏輯的實現(xiàn)，再加上當(dāng)前主流的微服務(wù) DevOps 容器調(diào)度的云原生解決方案思想。即我們當(dāng)前的應(yīng)用開發(fā)更加敏捷和高效，能夠快速的響應(yīng)業(yè)務(wù)的需求。

那么我們接著能夠考慮的就是在平臺層足夠強(qiáng)大后，我們的開發(fā)能否進(jìn)一步更加簡化，能夠?qū)崿F(xiàn)無代碼或少量代碼就能夠完成一個功能的開發(fā)和朝云端的部署上線。

比如我們現(xiàn)在看到的亞馬遜的公有云提供的ServerLess就是一個典型的場景。你只需要寫少量的配置文件或函數(shù)方法，就能夠完成一個類似網(wǎng)頁爬蟲，信息搜索，圖片存儲等互聯(lián)網(wǎng)功能。

第一：傳統(tǒng)的快速開發(fā)平臺

為了搞清楚低代碼開發(fā)，我們可以看下在原來我們經(jīng)常提到的快速開發(fā)平臺。對于原來我們談的快速開發(fā)平臺，我想可以初步分為兩種典型的類型。

• 面向業(yè)務(wù)人員：完全不需要開發(fā)經(jīng)驗，不用接觸代碼。典型是類似各種BPM可定制產(chǎn)品。
• 面向技術(shù)人員：提供快速開發(fā)平臺和工具，比如代碼自動生成，功能大部分可配置 腳本模式。

對于面向業(yè)務(wù)人員方式的平臺往往就是一個高度靈活的空平臺，所有的對象，數(shù)據(jù)，流程，規(guī)則，權(quán)限等你都可以隨意的配置和定制。類似各類BPM產(chǎn)品，但是實際上可以看到這類產(chǎn)品無法開發(fā)規(guī)則業(yè)務(wù)復(fù)雜的系統(tǒng)。

對于面向技術(shù)人員的快速開發(fā)平臺，類似我們常說的普元，JeeSite， JEPaaS，起步科技的PaaS平臺等都屬于這種類型。但是這種類型的平臺本身又細(xì)分為了兩種，一種是僅僅輔助開發(fā)和代碼生成，即所有的開發(fā)內(nèi)容都生成代碼，脫離開發(fā)平臺環(huán)境也能夠成功運行；還有一種就是強(qiáng)綁定，平臺很大內(nèi)容不生成代碼，對你黑盒，無法脫離環(huán)境運行。

對于起步JuStep的快速開發(fā)平臺和PaaS云，我沒有進(jìn)行試用，但是在10年前推出的快速開發(fā)平臺我試用過，這個企業(yè)能夠這么長周期的生存下來產(chǎn)品應(yīng)該自有一定的優(yōu)勢和能力。特別是現(xiàn)在提出的快速開發(fā)平臺和PaaS云 DevOps融合集成更是一個大趨勢。

即我們原來在談?wù)麄€云原生解決方案的時候，里面有一個內(nèi)容塊就是快速開發(fā)平臺和開發(fā)框架。

我原來比較強(qiáng)調(diào)技術(shù)開發(fā)類平臺是否提供源代碼，是否進(jìn)行強(qiáng)綁定，但是最近思考了下這個反而不是重點，真正重要的還是這個平臺對各類場景，各類業(yè)務(wù)需求下的通用模式抽象能力，這個將直接影響到平臺本身的好壞。比如一個平臺本身黑盒無法擴(kuò)展，但是你的業(yè)務(wù)場景又很難配置出來，那么整個平臺的可用性就大大的打折扣。

其次，對于一個快速開發(fā)平臺，我們可以有一個重要結(jié)論：你對不同業(yè)務(wù)，不同場景下的通用性適配能力越強(qiáng)大，那么你實際運行的黑盒代碼性能就越低。

也正是這個原因，我們看到很大快速開發(fā)平臺代碼臃腫，性能低下，你開發(fā)的時候速度倒是快了。但是后續(xù)系統(tǒng)的性能完全跟不上，也無法擴(kuò)展，這些都是要命的問題。

第二：從傳統(tǒng)快速開發(fā)到低代碼開發(fā)平臺

為了進(jìn)一步談我自己對低代碼開發(fā)平臺的理解，我先引用下網(wǎng)上對低代碼開發(fā)的一些定義和說明。

低代碼開發(fā)平臺是無需編碼（0代碼或無代碼）或通過少量代碼就可以快速生成應(yīng)用程序的開發(fā)平臺。它的強(qiáng)大之處在于，允許終端用戶使用易于理解的可視化工具開發(fā)自己的應(yīng)用程序，而不是傳統(tǒng)的編寫代碼方式。構(gòu)建業(yè)務(wù)流程、邏輯和數(shù)據(jù)模型等所需的功能，必要時還可以添加自己的代碼。完成業(yè)務(wù)邏輯、功能構(gòu)建后，即可一鍵交付應(yīng)用并進(jìn)行更新，自動跟蹤所有更改并處理數(shù)據(jù)庫腳本和部署流程，實現(xiàn)在 IOS，Android，Web 等多個平臺上的部署。

低代碼開發(fā)平臺(LCDP)英文全稱為Low-Code Development Platform,一個顯著的特點是，更多的人可以參與到應(yīng)用程序開發(fā)當(dāng)中，不僅是具有專業(yè)編程能力的程序員，非技術(shù)背景的業(yè)務(wù)人員同樣可以構(gòu)建應(yīng)用；對于大型企業(yè)來講，低代碼開發(fā)平臺還可以降低IT團(tuán)隊培訓(xùn)、技術(shù)部署的初始成本。

從這個定義上面我們可以找到一些關(guān)鍵點，簡單總結(jié)來說就是

1. 少量代碼或者無代碼，業(yè)務(wù)人員也能參與
2. 提供可視化，可配置的工具進(jìn)行配置和建模
3. 可同時發(fā)布到多個平臺或終端
4. 提供和云端的持續(xù)集成和發(fā)布能力，可持續(xù)交付，即我們常說的DevOps

對于低代碼開發(fā)平臺和快速開發(fā)平臺區(qū)別，實際我想強(qiáng)調(diào)一個重點，我個人認(rèn)為很重要，即：低代碼開發(fā)需要實現(xiàn)從最早的以數(shù)據(jù)庫對象建模方式轉(zhuǎn)變?yōu)榉?wù)化建模方式。

即快速開發(fā)平臺提供的能力應(yīng)該是各種技術(shù)服務(wù)和技術(shù)組件，我們前臺應(yīng)用的構(gòu)建能夠快速的使用和組裝這些能力服務(wù)，實現(xiàn)快速的可視化編排，這點大家也可以參考下JuStep快速平臺的思路。

由于我們自己沒有詳細(xì)試用，因此在這里不做評價。

傳統(tǒng)的快速開發(fā)平臺不論是表單或流程涉及，更多的還是圍繞數(shù)據(jù)庫為核心進(jìn)行，建立的對象可以生成數(shù)據(jù)庫。相關(guān)的表單操作也圍繞數(shù)據(jù)庫進(jìn)行。

而在低代碼開發(fā)時代，我個人更加推薦一個轉(zhuǎn)變，就是基于對象服務(wù)化的分層開發(fā)模式。這個本身也是更加貼近我當(dāng)前中臺和微服務(wù)的構(gòu)建思路。即你首先去構(gòu)建你的對象并發(fā)布你的服務(wù)，然后再考慮如何基于這些發(fā)布的服務(wù)類構(gòu)建上層的應(yīng)用。即我們的開發(fā)過程橫向拆分為兩端。而中間基于服務(wù)進(jìn)行松耦合連接。

即：微服務(wù) 服務(wù) 前端應(yīng)用。

不是簡單的我們傳統(tǒng)應(yīng)用拆分小了，而且我們的前端應(yīng)用模塊，后端能力模塊也全部微服務(wù)化，形成我們當(dāng)前說的平臺 中臺 前端應(yīng)用的分層模式。

這種模式如果再和我們當(dāng)前的DevOps和容器化技術(shù)結(jié)合，那么整個開發(fā)完成的應(yīng)用就更加容易持續(xù)發(fā)布和交付，也更加容易在后續(xù)繼續(xù)彈性資源擴(kuò)展和調(diào)度。

歡迎關(guān)注@人月聊IT 分享SOA，微服務(wù)，DevOps平臺規(guī)劃和建設(shè)。