關(guān)于低代碼方案評審指標(biāo)的思考（關(guān)于低代碼方案評審指標(biāo)的思考與建議）

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

1 運(yùn)行方式

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

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

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

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

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

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

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

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

2 頁面編輯器使用體驗(yàn)

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

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

3 定制化支持

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

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

4 前后端接口

前后端接口是否明確可控，這點(diǎn)很重要，因?yàn)榇蟛糠值痛a平臺都是同步生成前后端代碼的，但是這也就意味著他們根本沒有打算暴露一套規(guī)范可用的接口，如果在有額外定制化需求的前提下，這點(diǎn)就很致命了。

當(dāng)然在實(shí)際的情況下，不變才是不正常的。

5 后端計(jì)算棧

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

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

6 移動端適配

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

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

7 項(xiàng)目需求

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

免費(fèi)的東西最昂貴，軟件工程沒有銀彈（屠龍刀）?；谶@兩條原則，進(jìn)行方案選項(xiàng)實(shí)時，一定要明確項(xiàng)目的目標(biāo)，維護(hù)持續(xù)的周期，需要謹(jǐn)慎評估在整個生命周期下，能否被當(dāng)前的low code平臺涵蓋。

低代碼評審項(xiàng)目表