這周我差不多花了兩個半天的時間進一步研究了下網上的低程式碼開發平臺，也就是原來我們經常說的快速開發平臺。研究這個的一個主要原因就是我們看到在新的微服務，DevOps，ServerLess技術，前端新技術的發展趨勢下，低程式碼開發在時隔多年後被再一次的提起。
在微服務和雲原生解決方案不斷髮展的情況下，我們看到當前的雲服務已經從最傳統的彈性計算和儲存能力，提升到了我們常說的PaaS平臺層，即提供更多的類似訊息，快取，資料庫，中介軟體，安全，大資料平臺等平臺層服務能力。
有了這些共性技術服務能力後，應用開發就能夠基於這些共性技術服務能力，應用開發能夠更加只關注業務流程和業務邏輯的實現，再加上當前主流的微服務+DevOps+容器排程的雲原生解決方案思想。即我們當前的應用開發更加敏捷和高效，能夠快速的響應業務的需求。
那麼我們接著能夠考慮的就是再平臺層足夠強大後，我們的開發能否進一步更加簡化，能夠實現無程式碼或少量程式碼就能夠完成一個功能的開發和朝雲端的部署上線。比如我們現在看到的亞馬遜的公有云提供的ServerLess就是一個典型的場景。你只需要寫少量的配置檔案或函式方法，就能夠完成一個類似網頁爬蟲，資訊搜尋，圖片儲存等網際網路功能。
第一：傳統的快速開發平臺
為了搞清楚低程式碼開發，我們可以看下在原來我們經常提到的快速開發平臺。對於原來我們談的快速開發平臺，我想可以初步分為兩種典型的型別。
1. 面向業務人員：完全不需要開發經驗，不用接觸程式碼。典型是類似各種BPM高度流程表單可定製產品。
2. 面向技術人員：提供快速開發平臺和工具，比如程式碼自動生成，功能大部分可配置+指令碼編寫模式。
對於面向業務人員方式的平臺往往就是一個高度靈活的空平臺，所有的物件，資料，流程，規則，許可權等你都可以隨意的配置和定製。類似各類BPM產品，但是實際上可以看到這類產品無法開發規則業務複雜的系統。
對於面向技術人員的快速開發平臺，類似我們常說的普元，JeeSite， JEPaaS，起步科技的PaaS平臺等都屬於這種型別。但是這種型別的平臺本身又細分為了兩種，一種是僅僅輔助開發和程式碼生成，即所有的開發內容都生成程式碼，脫離開發平臺環境也能夠成功執行；還有一種就是強繫結，平臺很大內容不生成程式碼，對你黑盒，無法脫離環境執行。
我原來比較強調技術開發類平臺是否提供原始碼，是否進行強繫結，但是最近思考了下這個反而不是重點，真正重要的還是這個平臺對各類場景，各類業務需求下的通用模式抽象能力，這個將直接影響到平臺本身的好壞。比如一個平臺本身黑盒無法擴充套件，但是你的業務場景又很難配置出來，那麼整個平臺的可用性就大大的打折扣。
其次，對於一個快速開發平臺，我們可以有一個重要結論：
你對不同業務，不同場景下的通用性適配能力越強大，那麼你實際執行的黑盒程式碼效能就越低。
也正是這個原因，我們看到很大快速開發平臺程式碼臃腫，效能低下，你開發的時候速度倒是快了。但是後續系統的效能完全跟不上，也無法擴充套件，這些都是要命的問題。
第二：從傳統快速開發到低程式碼開發平臺
為了進一步談我自己對低程式碼開發平臺的理解，我先引用下網上對低程式碼開發的一些定義和說明。
低程式碼開發平臺是無需編碼（0程式碼或無程式碼）或通過少量程式碼就可以快速生成應用程式的開發平臺。它的強大之處在於，允許終端使用者使用易於理解的視覺化工具開發自己的應用程式，而不是傳統的編寫程式碼方式。構建業務流程、邏輯和資料模型等所需的功能，必要時還可以新增自己的程式碼。完成業務邏輯、功能構建後，即可一鍵交付應用並進行更新，自動跟蹤所有更改並處理資料庫指令碼和部署流程，實現在 IOS，Android，Web 等多個平臺上的部署。
低程式碼開發平臺(LCDP)英文全稱為Low-Code Development Platform,一個顯著的特點是，更多的人可以參與到應用程式開發當中，不僅是具有專業程式設計能力的程式設計師，非技術背景的業務人員同樣可以構建應用；對於大型企業來講，低程式碼開發平臺還可以降低IT團隊培訓、技術部署的初始成本。
從這個定義上面我們可以找到一些關鍵點，簡單總結來說就是
1. 少量程式碼或者無程式碼，業務人員也能參與
2. 提供視覺化，可配置的工具進行配置和建模
3. 可同時釋出到多個平臺或終端
4. 提供和雲端的持續整合和釋出能力，可持續交付，即我們常說的DevOps
對於低程式碼開發平臺和快速開發平臺區別，實際我想強調一個重點，我個人認為很重要，即：
低程式碼開發需要實現從最早的以資料庫物件建模方式轉變為服務化建模方式。
傳統的快速開發平臺不論是表單或流程涉及，更多的還是圍繞資料庫為核心進行，建立的物件可以生成資料庫。相關的表單操作也圍繞資料庫進行。
而在低程式碼開發時代，我個人更加推薦一個轉變，就是基於物件服務化的分層開發模式。這個本身也是更加貼近我當前中臺和微服務的構建思路。即你首先去構建你的物件併發布你的服務，然後再考慮如何基於這些釋出的服務類構建上層的應用。即我們的開發過程橫向拆分為兩端。而中間基於服務進行鬆耦合連線。
即：微服務 + 服務 + 前端應用。
不是簡單的我們傳統應用拆分小了，而且我們的前端應用模組，後端能力模組也全部微服務化，形成我們當前說的平臺+中臺+前端應用的分層模式。這種模式如果再和我們當前的DevOps和容器化技術結合，那麼整個開發完成的應用就更加容易持續釋出和交付，也更加容易在後續繼續彈性資源擴充套件和排程。
這周我差不多花了兩個半天的時間進一步研究了下網上的低程式碼開發平臺，也就是原來我們經常說的快速開發平臺。研究這個的一個主要原因就是我們看到在新的微服務，DevOps，ServerLess技術，前端新技術的發展趨勢下，低程式碼開發在時隔多年後被再一次的提起。
在微服務和雲原生解決方案不斷髮展的情況下，我們看到當前的雲服務已經從最傳統的彈性計算和儲存能力，提升到了我們常說的PaaS平臺層，即提供更多的類似訊息，快取，資料庫，中介軟體，安全，大資料平臺等平臺層服務能力。
有了這些共性技術服務能力後，應用開發就能夠基於這些共性技術服務能力，應用開發能夠更加只關注業務流程和業務邏輯的實現，再加上當前主流的微服務+DevOps+容器排程的雲原生解決方案思想。即我們當前的應用開發更加敏捷和高效，能夠快速的響應業務的需求。
那麼我們接著能夠考慮的就是再平臺層足夠強大後，我們的開發能否進一步更加簡化，能夠實現無程式碼或少量程式碼就能夠完成一個功能的開發和朝雲端的部署上線。比如我們現在看到的亞馬遜的公有云提供的ServerLess就是一個典型的場景。你只需要寫少量的配置檔案或函式方法，就能夠完成一個類似網頁爬蟲，資訊搜尋，圖片儲存等網際網路功能。
第一：傳統的快速開發平臺
為了搞清楚低程式碼開發，我們可以看下在原來我們經常提到的快速開發平臺。對於原來我們談的快速開發平臺，我想可以初步分為兩種典型的型別。
1. 面向業務人員：完全不需要開發經驗，不用接觸程式碼。典型是類似各種BPM高度流程表單可定製產品。
2. 面向技術人員：提供快速開發平臺和工具，比如程式碼自動生成，功能大部分可配置+指令碼編寫模式。
對於面向業務人員方式的平臺往往就是一個高度靈活的空平臺，所有的物件，資料，流程，規則，許可權等你都可以隨意的配置和定製。類似各類BPM產品，但是實際上可以看到這類產品無法開發規則業務複雜的系統。
對於面向技術人員的快速開發平臺，類似我們常說的普元，JeeSite， JEPaaS，起步科技的PaaS平臺等都屬於這種型別。但是這種型別的平臺本身又細分為了兩種，一種是僅僅輔助開發和程式碼生成，即所有的開發內容都生成程式碼，脫離開發平臺環境也能夠成功執行；還有一種就是強繫結，平臺很大內容不生成程式碼，對你黑盒，無法脫離環境執行。
我原來比較強調技術開發類平臺是否提供原始碼，是否進行強繫結，但是最近思考了下這個反而不是重點，真正重要的還是這個平臺對各類場景，各類業務需求下的通用模式抽象能力，這個將直接影響到平臺本身的好壞。比如一個平臺本身黑盒無法擴充套件，但是你的業務場景又很難配置出來，那麼整個平臺的可用性就大大的打折扣。
其次，對於一個快速開發平臺，我們可以有一個重要結論：
你對不同業務，不同場景下的通用性適配能力越強大，那麼你實際執行的黑盒程式碼效能就越低。
也正是這個原因，我們看到很大快速開發平臺程式碼臃腫，效能低下，你開發的時候速度倒是快了。但是後續系統的效能完全跟不上，也無法擴充套件，這些都是要命的問題。
第二：從傳統快速開發到低程式碼開發平臺
為了進一步談我自己對低程式碼開發平臺的理解，我先引用下網上對低程式碼開發的一些定義和說明。
低程式碼開發平臺是無需編碼（0程式碼或無程式碼）或通過少量程式碼就可以快速生成應用程式的開發平臺。它的強大之處在於，允許終端使用者使用易於理解的視覺化工具開發自己的應用程式，而不是傳統的編寫程式碼方式。構建業務流程、邏輯和資料模型等所需的功能，必要時還可以新增自己的程式碼。完成業務邏輯、功能構建後，即可一鍵交付應用並進行更新，自動跟蹤所有更改並處理資料庫指令碼和部署流程，實現在 IOS，Android，Web 等多個平臺上的部署。
低程式碼開發平臺(LCDP)英文全稱為Low-Code Development Platform,一個顯著的特點是，更多的人可以參與到應用程式開發當中，不僅是具有專業程式設計能力的程式設計師，非技術背景的業務人員同樣可以構建應用；對於大型企業來講，低程式碼開發平臺還可以降低IT團隊培訓、技術部署的初始成本。
從這個定義上面我們可以找到一些關鍵點，簡單總結來說就是
1. 少量程式碼或者無程式碼，業務人員也能參與
2. 提供視覺化，可配置的工具進行配置和建模
3. 可同時釋出到多個平臺或終端
4. 提供和雲端的持續整合和釋出能力，可持續交付，即我們常說的DevOps
對於低程式碼開發平臺和快速開發平臺區別，實際我想強調一個重點，我個人認為很重要，即：
低程式碼開發需要實現從最早的以資料庫物件建模方式轉變為服務化建模方式。
傳統的快速開發平臺不論是表單或流程涉及，更多的還是圍繞資料庫為核心進行，建立的物件可以生成資料庫。相關的表單操作也圍繞資料庫進行。
而在低程式碼開發時代，我個人更加推薦一個轉變，就是基於物件服務化的分層開發模式。這個本身也是更加貼近我當前中臺和微服務的構建思路。即你首先去構建你的物件併發布你的服務，然後再考慮如何基於這些釋出的服務類構建上層的應用。即我們的開發過程橫向拆分為兩端。而中間基於服務進行鬆耦合連線。
即：微服務 + 服務 + 前端應用。
不是簡單的我們傳統應用拆分小了，而且我們的前端應用模組，後端能力模組也全部微服務化，形成我們當前說的平臺+中臺+前端應用的分層模式。這種模式如果再和我們當前的DevOps和容器化技術結合，那麼整個開發完成的應用就更加容易持續釋出和交付，也更加容易在後續繼續彈性資源擴充套件和排程。