我之前體驗過較多低代碼平臺，也寫過一些關于這些方面的文章，但大多數都僅停留在應用層面或是表層，這次我想來正式討論一下低代碼這個問題。
低代碼，顧名思義，就是能少寫代碼就少寫代碼，以較少的代碼調整量與大量模塊化模板調整從而達成在較少時間內交付出較為完善的應用程序。
可以這么說，低代碼和模塊化、可視化等關鍵詞聯系緊密，通過對預置模板的“拖拉拽”等方式達成項目的搭建。
現在的低代碼主要都是在講述業務等辦公領域的應用，但要真正討論起來，計算機本身發展的過程就是追求輕量化代碼的過程，從機器語言到匯編語言，再到C++，Python等高級語言，之后對于這些高級語言，有越來越多的類庫加入，比如C++的STL庫，方便了程序員的代碼書寫與理解；之后就是基于這些語言的開發軟件，這些開發軟件會預先提供部分模塊（比如Unity的AR Foundation模塊就是為了開發增強現實項目而準備的基礎模塊，當引用這一模塊時，可以直接使用預設腳本導入到物體上，無需進入代碼修改只需在Unity設計界面中對部分參數、引用做出可視化調整即可），通過這些模塊，使得開發的過程能少寫一些內容并對模塊有清晰的了解，除去上面舉例的Unity之外，還有很多初學者甚至幾乎沒有代碼基礎的人青睞的軟件——RPG Maker系列，如果說Unity雖然方便了項目開發，但還是需要理解并寫大量C#腳本來構建項目，那么基于JS或Ruby的RPG Maker系列可以說如果只是簡單開發，幾乎不需要任何代碼就能編寫經典的rpg游戲出來，盡管范圍只局限在游戲開發中。這也是最為貼近低代碼開發的一個例子。這些東西的研發歷史都是早于低代碼這一概念的正式提出的。
2014年，Forrester首次定義“Low-Code Development Platforms”，即低代碼開發平臺，在其發布的研究報告《New Development Platforms Emerge For Customer-Facing Applications》中，Forrester將低代碼開發平臺定義為："通過可視化編程和模型驅動邏輯，實現快速應用開發的平臺，同時支持專業開發者和普通業務用戶共同參與開發過程。"報告中詳細闡述了低代碼平臺存在的幾個關鍵特征：
可視化開發界面：主要通過拖拽組件和配置參數的方式構建應用，大幅減少傳統代碼編寫量
模型驅動開發：采用聲明式編程范式，開發者通過定義業務邏輯模型而非編寫具體代碼
自動化功能：包括自動生成代碼、自動測試、一鍵部署等能力
多角色協作：支持專業開發者和業務人員在同一平臺上協作
中國的低代碼平臺大致就是從這個時期開始萌芽，這一時期國內互聯網行業蓬勃發展，傳統企業數字化轉型需求激增，同時移動互聯網普及帶來對快速開發工具的需求，涌現出了很多本土低代碼平臺，比如氚云、簡道云、阿里云·宜搭等等，然后在疫情期間瞬間爆發需求與發展，最后進入平穩的發展期。
計算機學習的過程中我們應該會學習到一個不同于編程語言的語言——UML，即統一建模語言，是一種用于軟件系統分析和設計的可視化建模語言，它通過標準化的圖形符號來幫助開發者更清晰地表達軟件系統的架構、行為和邏輯結構，包括用例圖，類圖，時序圖，活動圖等。其不直接用于編寫可執行代碼，而是作為溝通工具幫助開發團隊在項目前期達成共識。但事實上由于UML和實際代碼的分離性，學生們對于UML的想象可能就止步于作業和考試要你畫的一堆圖中，在實際寫前后端代碼時根本不會去畫圖而是直奔著Controller之類的東西就開始框框寫，即使考慮到了，但又可能因為精力有限，UML圖考慮不周全，當發現需要增加什么用例或類時，帶來的修改量也是較大的；對于開發者來說也有可能存在著這些問題。
UBML，即統一商務建模語言，相比之前提到的UML，最大的區別就在于和實際代碼的聯系，UML不依賴于具體代碼實現，是面向傳統軟件的開發，提供系統分析、設計的通用建模工具，使用效果因人而異，對于缺乏項目管理經驗的人來講，用起來就會比較麻煩，而UBML則是專門為低代碼平臺設計的，強調業務邏輯與應用開發的直接映射的建模語言，目標是通過模型驅動開發快速生成企業級應用（如ERP、OA），當你理清建模時，一個程序可能隨之而來的就做好了（這主要是因為其核心模型在于業務實體、流程、界面、規則，當你在低代碼平臺對模塊“拖拉拽”時，你也在理清模塊之間的關系）。同時由于UBML是由中國機構推動且目前運用在國內生態中的，其語法，圖形等是為國內項目習慣定制的，便于國人理解與使用。
inBuilder作為承載UBML的低代碼平臺，負責了從建模到實現的關鍵步驟，當你在UBML層面把業務流程、數據結構、頁面邏輯等模型都拖拉拽好，之后inBuilder就會為你準備好相應的數據庫、后端接口、前端頁面、審批流程等，根據這些模型與inBuilder的準備，就能生成一套可運行的系統。
從我之前對inBuilder和UBML的應用來看，確實可以不依靠寫代碼，在搭好環境的前提下就能簡單滿足業務需求，并且在這種條理性的步驟中理解這些業務的相互關系。對于學生群體來說，在已有前后端學習經驗的基礎上，快速上手UBML+inBuilder，既能搭建完整系統，又能鍛煉邏輯思維與建模能力，為以后的項目構筑打好基礎；對于獨立開發者來說，無需團隊支持，一人即可完成從建模到系統開發的全流程，省去了前后端協作成本；對于企業IT人員來說，可以高效開發內部系統（如審批流、信息管理），貼合低代碼模式，縮短交付周期；對于業務/產品人員來說，可以直接參與業務建模，用可視化工具溝通需求，減少傳統開發中的設計等待環節。
有人擔憂低代碼平臺會剝奪程序員的生存空間，似乎有可能，但可能性又不是很大。目前的低代碼平臺并非智能，很多都僅僅能滿足基本需求，即使結合了當今的AI來看，還是無法解決這個問題，當場景變得復雜的時候，你還是要寫代碼，而且可能要付出更高的代價。低代碼的出現，一方面確實可以讓程序員少寫代碼，從而將精力放到更艱難的開發維護等方面，但其作用不止于此，更多的一方面是其還原了業務開發的全過程——從需求到實現，能讓程序員更多的去審視自己的開發過程，了解系統模塊，數據流動，用戶行為與流程的相互作用等問題，使開發代碼的書寫代價進一步降低。而開源的低代碼平臺更是可以讓你體會到你所設計的項目與其背后的代碼之間的聯系，為后續可能存在的項目模塊擴展建立基礎。
低代碼降低了普通人的開發門檻，卻也為程序員提出了更高的要求。未來的開發之路，設計模型遠遠比埋頭寫代碼重要，在系統各模塊統一表達的平臺中，程序員更應該具有建模思想。