什麼是低代碼
Low-code development platform。
從Wiki的這段定義中，我們可以提煉出幾個關鍵資訊：
- 低代碼開發平台（LCDP）本身也是一種軟體，它為開發者提供了一個建立應用軟體的開發環境。看到“開發環境”幾個字是不是很親切？對于程式員而言，低代碼開發平台的性質與IDEA、VS等代碼IDE（內建開發環境）幾乎一樣，都是服務于開發者的生産力工具。
- 與傳統代碼IDE不同的是，低代碼開發平台提供的是更高維和易用的可視化IDE。大多數情況下，開發者并不需要使用傳統的手寫代碼方式進行程式設計，而是可以通過圖形化拖拽、參數配置等更高效的方式完成開發工作。
低代碼核心能力
低代碼開發平台的核心能力：
- 全棧可視化程式設計：可視化包含兩層含義，一個是編輯時支援的點選、拖拽和配置操作，另一個是編輯完成後所及即所得（WYSIWYG）的預覽效果。傳統代碼IDE也支援部分可視化能力（如早年Visual Studio的MFC/WPF），但低代碼更強調的是全棧、端到端的可視化程式設計，覆寫一個完整應用開發所涉及的各個技術層面（界面/資料/邏輯）。
- 全生命周期管理：作為一站式的應用開發平台，低代碼支援應用的完整生命周期管理，即從設計階段開始（有些平台還支援更前置的項目與需求管理），曆經開發、建構、測試和部署，一直到上線後的各種運維（e.g. 監控報警、應用上下線）和營運（e.g. 資料報表、使用者回報）。
- 低代碼擴充能力：使用低代碼開發時，大部分情況下仍離不開代碼，是以平台必須能支援在必要時通過少量的代碼對應用各層次進行靈活擴充，比如添加自定義元件、修改主題CSS樣式、定制邏輯流動作等。一些可能的需求場景包括：UI樣式定制、遺留代碼複用、專用的加密算法、非标系統內建。
為什麼需要低代碼
低代碼是什麼可能并沒那麼重要，畢竟在這個資訊爆炸的世界，永遠不缺少新奇而又短命的事物。大部分所謂的新技術都隻是昙花一現：出現了，被看到了；大部分人“哦”了一聲，已閱但表示不感興趣；小部分人驚歎于它的奇思妙想，激動地點了個贊後，回過頭來該用什麼還是什麼。真正決定新技術是否能轉化為新生産力的，永遠不是技術本身有多麼優秀和華麗，而是它是否真的被需要，
為什麼「市場」需要低代碼？
在這個大爺大媽都滿嘴“網際網路+”和“數字化轉型”的時代，企業越來越需要通過應用（App）來改善企業内部的資訊流轉、強化與客戶之間的觸點連接配接。然而，誕生還不太久的IT資訊時代，也正面臨着與我國社會主義初級階段類似的供需關系沖突：落後的軟體開發生産力跟不上人民日益增長的業務需求。
我們看到一個現象，經濟日漸下行，但是編碼人員的招聘依然火熱。
Gartner預測，到2021年應用開發需求的市場增長将至少超過企業IT傳遞能力的5倍。面對如此巨大的IT缺口，如果沒有一種革命性的“新生産力”體系，很難想象僅憑現有傳統技術體系的發展延續就能徹底解決問題。而低代碼技術正是帶着這樣的使命而降臨，期望通過以下幾個方面徹底革新應用開發生産力，拯救差一點就要邁入水深火熱的IT世界：
提效降本 & 品質保障
雖然軟體行業一直在高速發展，新的語言、架構和工具層出不窮，但作為從業者我們不得不承認：軟體開發仍處于手工作坊階段，效率低、人力成本高、品質不可控。項目延期傳遞已成為行業常态，而瓶頸幾乎總是開發人員（對機器能解決的問題都不是問題）；優秀的開發人才永遠是稀缺資源，還賊貴；軟體品質缺陷始終無法收斂，線上故障頻發資損不斷。
相比而言，傳統制造業經過幾百年工業革命的發展，大部分早已擺脫了對“人”的強依賴：從原料輸入到制品輸出，中間是各種精密儀器和自動化流水線的穩定支撐，真正實作生産的标準化和規模化。雖然資訊化号稱是人類的第三次工業革命，但以軟體行業目前的狀況，遠遠還沒到達成熟的“工業化”階段。
加強開發過程的溝通協作
多方調查結果顯示，軟體項目失敗的最主要原因之一就是缺乏溝通（poor communication）。傳統開發模式下，業務、産品、設計、開發、測試與運維人員各司其職，且各有一套領域内的工具和語言，長久以來很容易形成一個個“豎井”（silos），讓跨職能的溝通變得困難而低效。這也是為什麼目前熱門的靈活開發和DevOps都在強調溝通（前者是協同Biz與Dev，而後者是協同Dev和Ops），而經典的DDD領域驅動設計也主張通過“統一語言”來減少業務與技術人員之間的溝通不一緻。
有了低代碼後，這一狀況将得到根本改善：上述各角色都可以在同一個低代碼開發平台上緊密協作（甚至可以是同一個人），這種全新的協作模式不僅打破了職能豎井，還能通過統一的可視化語言和單一的應用表示（頁面/資料/邏輯），輕松對齊項目各方對應用形态和項目進度的了解，實作更終極的靈活開發模式，以及在傳統DevOps基礎之上更進一步的BizDevOps[2]。
也就是說，可以根據需求的不斷變化而不斷變化。
擴大應用開發勞動力
通過讓大部分開發工作可以僅通過簡單的拖拽與配置完成，低代碼（包括零代碼）顯著降低了使用者門檻，讓企業能夠充分利用前面所提到的平民開發者資源。部分純零代碼需求場景下，低代碼還能讓業務人員實作自助式（self-service）應用傳遞，既解決了傳統IT傳遞模式下的任務堆積（backlog）問題，避免稀缺的專業開發資源被大量簡單、重複性的應用開發需求所侵占，也能讓業務人員真正按自己的想法去實作應用，擺脫交由他人開發時不可避免的桎梏。
至此，應用開發能力不再是少數專業開發者的專利和特權，且今後所需要的技能門檻與擁有成本也會越來越低，真正實作所謂的“技術民主化”（democratization of technology）。
低代碼的前世今生以及應用
三豐，公衆号：soft張三豐【解析】從MDA到低代碼
MyBatis-Plus
低代碼是什麼可能并沒那麼重
目前最新版本
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus</artifactId>
<version>3.5.2</version>
</dependency> 架構結構
生态圈
- MybatisX (opens new window)- 一款全免費且強大的 IDEA 插件，支援跳轉，自動補全生成 SQL，代碼生成。
- Mybatis-Mate (opens new window)- 為 MyBatis-Plus 企業級子產品，支援分庫分表、資料審計、字段加密、資料綁定、資料權限、表結構自動生成 SQL 維護等進階特性。
- Dynamic-Datasource (opens new window)- 基于 SpringBoot 的多資料源元件，功能強悍，支援 Seata 分布式事務。
- Shuan (opens new window)- 基于 Pac4J-JWT 的 WEB 安全元件, 快速內建。
- Kisso (opens new window)- 基于 Cookie 的單點登入元件。
- Lock4j (opens new window)- 基于 SpringBoot 同時支援 RedisTemplate、Redission、Zookeeper 的分布式鎖元件。
- Kaptcha (opens new window)- 基于 SpringBoot 和 Google Kaptcha 的簡單驗證碼元件，簡單驗證碼就選它。
- Aizuda 愛組搭 (opens new window)- 低代碼開發平台元件庫。
相信很多人都用過這幾款代碼庫。
然後我們看看插件方式的生成
選中要生成的表，并根據具體情況修改相關配置，最後點選右下角code generatro生成代碼
生成後即可完成基本的示範功能。工具簡單又好用，工作事半又功倍，把時間留給自己，做自己想做的事。
其實這是一個對于程式人員來說非常适合的工具，但也隻是一個工具而已，使用它之前你必須要有相關的基礎，不然在使用的過程中就會産生很多莫名其妙的問題，是不是很适合我們之前提過的28原則，很多基礎的業務問題都可以通過這種生成的方式快速解決。
28原則
三豐，公衆号：soft張三豐【性能】性能分析原則
maku-boot
- maku-boot 是采用 SpringBoot、SpringSecurity、Mybatis-Plus 等架構，開發的一套 SpringBoot 快速開發平台，使用門檻極低，且采用 MIT 開源協定，完全免費開源，可免費用于商業項目等場景。
- 采用元件模式，擴充不同的業務功能，可以很友善的實作各種業務需求，且不會導緻系統臃腫，若想使用某個元件，按需引入即可，反之亦然。
開發文檔
https://maku.net/docs/maku-boot 示範環境
https://demo.maku.net/maku-boot 效果圖
生成代碼工具和低代碼一樣嗎
關注公衆号 soft張三豐