最近工作需要，接觸參加了一些低代碼平臺的選型工作，但是作為為數(shù)不多接觸過web開發(fā)的人，我實在是受不了大家聽廣告津津有味的作風，于是從項目角度、從技術角度，給出了評價低代碼平臺方案的評價標準，特記錄如下。

1 運行方式

• 編譯為靜態(tài)文件(html，js，css)

這種是最理想的，但是無疑也是成本最高的

• 運行時候前端(瀏覽器)動態(tài)渲染

拖拉拽創(chuàng)建頁面時候，只記錄頁面的配置信息，瀏覽器加載固定的前端代碼，根據(jù)配置信息運行時候動態(tài)地解析渲染頁面

• 運行時候后端動態(tài)生成前端(動態(tài)頁面)

拖拉拽創(chuàng)建頁面時候生成的頁面的配置信息，會被后端保存管理，瀏覽器訪問時候，后端根據(jù)配置生成web頁面（也可以稱為后端渲染，雖然渲染這個詞用在后端顯得怪怪的。

最優(yōu)是生成靜態(tài)頁面文件，次優(yōu)是前端渲染，當然這一切都是基于預算充足的情況，沒錢就因陋就簡吧。

我把技術方案放在了易用性的前面，一方面是我對技術的偏愛，另一方面是因為這足以決定后續(xù)項目的維護和擴增，比較如果有可能，我們還是希望一套方案可以從demo用到上線到一定量。

2 頁面編輯器使用體驗

這也就是所謂的"拖拉拽"。低代碼是給非專業(yè)用戶使用的，自然ui化的頁面編輯器是重中之重，基本的要求如下:

• 提供布局功能(有的low code方案真的沒有)，且要足夠易用(千萬別搞成css翻譯器)
• 要涵蓋常用的組件
• 組件可以進行可視化的樣式調節(jié)，不求拖拉調整，至少應該保證可以便捷地輸入數(shù)值。
• 不能卡頓，不能出錯，容器嵌套時候選中不能錯層。這也是最基本的，也是最后各個方案進行比拼的基本。

3 定制化支持

明確是否可以進行樣式調節(jié)，是否可以嵌入js代碼。因為盡管低代碼平臺目的就是適用簡單業(yè)務場景，但是現(xiàn)實情況是很不講道理的，所以為了應對某些考慮不到的意外情況，還是要考慮定制化支持的(當然，如果有鈔能力，供應商可以無腦給定制需求，哪這點就直接跳過)。

主要看定制化方式，如果可以支持內嵌html、css、js，且足夠簡單易用，無額外學習成本，自然是最好的，因為個人經(jīng)驗是工程師們很抗拒學習不知名的技術方案。

4 前后端接口

前后端接口是否明確可控，這點很重要，因為大部分低代碼平臺都是同步生成前后端代碼的，但是這也就意味著他們根本沒有打算暴露一套規(guī)范可用的接口，如果在有額外定制化需求的前提下，這點就很致命了。

當然在實際的情況下，不變才是不正常的。

5 后端計算棧

如果low code方案包含了后端代碼生成，應該考慮后端代碼技術棧，修改維護的難易程度。

相較而言，后端更容易修改，這也就意味著會有更多的

6 移動端適配

如果有移動端需求，要考慮移動端適配

好的組件庫應該是默認做了移動端適配的，尤其是業(yè)務中需要移動端使用的，一定要考究這一點功能，否則到時候又要有額外的開銷。

7 項目需求

一切的目的是業(yè)務(畢竟都用低代碼了，應該沒有人在意技術實現(xiàn)和性能)，如果可以滿足業(yè)務需求，且項目沒有改進需求，沒有持續(xù)長時間運維需求，上面提的其實都不重要。

免費的東西最昂貴，軟件工程沒有銀彈（屠龍刀）。基于這兩條原則，進行方案選項實時，一定要明確項目的目標，維護持續(xù)的周期，需要謹慎評估在整個生命周期下，能否被當前的low code平臺涵蓋。

低代碼評審項目表