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

簡(jiǎn)介：多年SOA規(guī)劃建設(shè)，私有云PaaS平臺(tái)架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)，長(zhǎng)期從事一線項(xiàng)目實(shí)踐

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

快速開(kāi)發(fā)平臺(tái)本身的欠缺點(diǎn)

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

當(dāng)然就公司來(lái)說(shuō)本身也有一個(gè)積累了很多年的技術(shù)平臺(tái)，要上升到產(chǎn)品化的快速開(kāi)發(fā)平臺(tái)還有一定距離，但是也足夠我們?nèi)粘ｍ?xiàng)目使用。其中最重要的就是流程引擎和4A，還有就是共性的技術(shù)組件的抽取和積累。

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

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

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

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

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

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

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

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

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

快速開(kāi)發(fā)平臺(tái)的優(yōu)勢(shì)在哪里？

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

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

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

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

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

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

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

http://www.jepaas.com/

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

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

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

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

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

從快速開(kāi)發(fā)平臺(tái)到低代碼平臺(tái)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

從這個(gè)定義上面我們可以找到一些關(guān)鍵點(diǎn)，簡(jiǎn)單總結(jié)來(lái)說(shuō)就是

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

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

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

由于我們自己沒(méi)有詳細(xì)試用，因此在這里不做評(píng)價(jià)。

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

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

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

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

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

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