我眼中的低程式碼（一）：什麼是低程式碼？

低程式碼是什麼？

這個問題，我最近一直在思考，我是一個個開（算是一個全棧），最近在各種文章和專案中不斷看到低程式碼，low code等相關名詞。由此便生出了不小的興趣。

從多個平臺多個專案不斷的來看。出現的原因有以下幾點：

1. 前端人員太少：是的，你沒看錯，低程式碼出現最大的原因是因為前端人員太少或者成本太高造成的，需要一個低程式碼平臺來降低一個或者多個專案建立和維護工作的工作量和複雜程度。
2. 統一UI互動規範：現在一個前端專案動則幾G，更不用說大型的專案的大小了，一個朋友給我說，他們有一個平臺，32G的大小，在拆成微服務後最大的也有3G的體積。其中各種庫，包，外掛，已經讓主創團隊無法把握了。因為廠子比較大，多個團隊協作，幾十個人玩這一個專案，人來人去，水平有高有低，UI的規範，庫的內容，已經完全無法確認重複和標準。所以需要一個子團隊主力基礎ui元件的開發和維護工作 ，其他團隊只進行業務邏輯的開發和維護工作，這就帶來了一個問題，怎麼讓其他團隊能按照標準來開發和維護？
3. 開發門檻 ：目前企業資訊化非常快，常常一個任務還沒完成，基於此任務的任務就已經出現多個。但是與之相對的是開發團隊人員的數量和質量。所以這就有一個想法，讓客戶（使用者）參與進來。但是客戶不懂技術，我們需要讓他們點點點，就能完成他們需求的業務邏輯。
4. 前端更新太快了：我有一個以前的專案，大概有個6年左右的歷史，裡面有JQ，vue1，vue2，EasyUI等各種前端的庫，其中有有些庫在更新，但是裡面有多個版本比如：jqxxx，另外還有很多庫已經不再更新了。現在每次想把他重構一次，然後的工作就是：坐下->開啟專案->看程式碼->放棄。所以專案需要一個方案或者標準，對現在的專案進行抽象，將其包裝為JSON或者其他物件，然後用這些高階集合體，去轉為目標物件。
5. 其他還有很多的原因：跨團隊/公司協作，業務需求（工作流）等等。

低程式碼的適用範圍

目前來看，低程式碼平臺的適用範圍主要是取決於各個專案的設計和整體設計規範的。

有的是不適於 大量定製 UI ， 極為複雜或特殊的互動 ；

有的對非開發文員有較高的門檻；

有的是因為協議和商業平臺等的限制；

低程式碼目前的現狀

各大平臺專案，尚未見到統一或者說具有強優勢的標準。

低程式碼平臺參考

1. Extjs：你敢相信麼，他在0幾年就已經初步完成了低程式碼的初步概念和工作，雖然沒有以低程式碼來宣傳，其實以當前市面上我見到各種平臺和專案來說，它是最強的。以其特殊的載入方式和基礎元件庫，完成了MVVM/低程式碼/微前端等等的工作。除了收費，簡直完美。
2. amis：一個目前我覺得仍在進步中的低程式碼框架，我個人覺得最大的缺點是函式要寫成字串的形式，這個實在是太蛋疼了，希望可以像ext一樣的進行以類而不是json的形式進行程式的載入。但是瑕不掩瑜，amis真的很適合在低程式碼平臺的搭建。相比其他的框架有：現成的視覺化編輯器，遠端載入等優點。
3. J2Paas ：這是一個相對較成熟的專案,缺點是和後端繫結太深了，我覺得一個優秀的低程式碼框架最應該做的的是與後端無關。當然這是一個前後端一體化的專案，所以這也是此類系統的優點，拿來就能用。
4. 還有其他的很多低程式碼專案和框架就不一一列舉，上面三個是目前我覺得值得拿來研究，也可以看到程式碼的幾個低程式碼平臺。

本文如有您覺得不合適的地方請回復，我會及時改正。