最近工作需要，接触参加了一些低代码平台的选型工作，但是作为为数不多接触过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平台涵盖。
低代码评审项目表
|
编号 | 项目 | 子项目 | |||
1 | 运行方式 | 编译为静态文件 | 前端动态渲染 | 后端动态生成 | |
2 | 编辑器使用体验 | 布局功能 | |||
组件涵盖 | |||||
样式调整 | |||||
内置主题&icon | |||||
流畅性&稳定性 | |||||
3 | 定制化支持 | css样式代码嵌入 | |||
js代码嵌入 | |||||
4 | 前后端接口明确 | ||||
5 | 后端技术栈 | 开发语言&技术栈 | |||
代码质量 | |||||
维护难度 | |||||
6 | 移动端适配 | ||||
7 | 业务需求 | 涵盖项目周期 | |||
满足业务需求 | |||||
可维护性 |
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
