关于低代码方案评审指标的思考（关于低代码方案评审指标的思考与建议）

最近工作需要，接触参加了一些低代码平台的选型工作，但是作为为数不多接触过web开发的人，我实在是受不了大家听广告津津有味的作风，于是从项目角度、从技术角度，给出了评价低代码平台方案的评价标准，特记录如下。

1 运行方式

• 编译为静态文件(html，js，css)

这种是最理想的，但是无疑也是成本最高的

• 运行时候前端(浏览器)动态渲染

拖拉拽创建页面时候，只记录页面的配置信息，浏览器加载固定的前端代码，根据配置信息运行时候动态地解析渲染页面

• 运行时候后端动态生成前端(动态页面)

拖拉拽创建页面时候生成的页面的配置信息，会被后端保存管理，浏览器访问时候，后端根据配置生成web页面（也可以称为后端渲染，虽然渲染这个词用在后端显得怪怪的。

最优是生成静态页面文件，次优是前端渲染，当然这一切都是基于预算充足的情况，没钱就因陋就简吧。

我把技术方案放在了易用性的前面，一方面是我对技术的偏爱，另一方面是因为这足以决定后续项目的维护和扩增，比较如果有可能，我们还是希望一套方案可以从demo用到上线到一定量。

2 页面编辑器使用体验

这也就是所谓的"拖拉拽"。低代码是给非专业用户使用的，自然ui化的页面编辑器是重中之重，基本的要求如下:

• 提供布局功能(有的low code方案真的没有)，且要足够易用(千万别搞成css翻译器)
• 要涵盖常用的组件
• 组件可以进行可视化的样式调节，不求拖拉调整，至少应该保证可以便捷地输入数值。
• 不能卡顿，不能出错，容器嵌套时候选中不能错层。这也是最基本的，也是最后各个方案进行比拼的基本。

3 定制化支持

明确是否可以进行样式调节，是否可以嵌入js代码。因为尽管低代码平台目的就是适用简单业务场景，但是现实情况是很不讲道理的，所以为了应对某些考虑不到的意外情况，还是要考虑定制化支持的(当然，如果有钞能力，供应商可以无脑给定制需求，哪这点就直接跳过)。

主要看定制化方式，如果可以支持内嵌html、css、js，且足够简单易用，无额外学习成本，自然是最好的，因为个人经验是工程师们很抗拒学习不知名的技术方案。

4 前后端接口

前后端接口是否明确可控，这点很重要，因为大部分低代码平台都是同步生成前后端代码的，但是这也就意味着他们根本没有打算暴露一套规范可用的接口，如果在有额外定制化需求的前提下，这点就很致命了。

当然在实际的情况下，不变才是不正常的。

5 后端计算栈

如果low code方案包含了后端代码生成，应该考虑后端代码技术栈，修改维护的难易程度。

相较而言，后端更容易修改，这也就意味着会有更多的

6 移动端适配

如果有移动端需求，要考虑移动端适配

好的组件库应该是默认做了移动端适配的，尤其是业务中需要移动端使用的，一定要考究这一点功能，否则到时候又要有额外的开销。

7 项目需求

一切的目的是业务(毕竟都用低代码了，应该没有人在意技术实现和性能)，如果可以满足业务需求，且项目没有改进需求，没有持续长时间运维需求，上面提的其实都不重要。

免费的东西最昂贵，软件工程没有银弹（屠龙刀）。基于这两条原则，进行方案选项实时，一定要明确项目的目标，维护持续的周期，需要谨慎评估在整个生命周期下，能否被当前的low code平台涵盖。

低代码评审项目表