低代码平台选型时，一定要评估的哪几个方面？
转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。
目前低代码技术正处在风口，低代码平台产品不断涌现，乱花渐欲迷人眼。作为软件公司或企业IT部门的负责人，在做低代码平台选型时需要关注哪些方面，才能顺利“上车”，让低代码为自己的团队赋能？
除了产品功能是否满足当前项目需求，价格是否在预算范围内之外，以下几个问题的答案同样重要。
Q1：是否支持协同开发和版本管理？
项目开发过程中，我们难免遇到客户反馈某个新开发的功能没有用，但是过一段时间以后反悔，又希望加回来的情况。这是软件开发的常态。为了解决这一问题，传统的软件开发团队都会引入版本管理机制，低代码也不例外。面对频繁的需求变更、棘手的问题排查，低代码平台的版本管理，特定模块回滚等操作的价值就会体现出来。
此外，为了加速项目的交付速度，我们通常需要集中更多人员进行同步开发。只有具备协同开发能力的低代码平台才能让这一过程变得可管理，避免混乱。
所以，不论项目规模大小，选择一款兼容主流代码库、支持敏捷开发的低代码平台都会对开发工作有所帮助。
（Git：一款主流的版本控制系统，图片来自Git官网）
Q2：是否支持自由设计数据库结构？
数据库是所有企业管理软件的“地基”。为了后续功能的开发更加方便，扩展性更强，维护性更佳，良好的数据库设计至关重要。这个点是企业软件自身的属性决定的，无论是低代码还是传统的纯代码，都不会有变化。
事实上，软件开发技术发展到今天，数据库设计的最佳实践早已被总结成了久经考验的数据库设计范式。低代码开发平台是否能够对开发者开放数据库结构的自由设计能力，能够让开发者基于数据库设计范式不断优化数据结构，直接决定了该平台的专业性。如果你需要开发高标准的核心业务应用，或者对应用后期的可扩展性、可维护性有要求，那么数据库设计能力在评估过程中至关重要。
（满足设计范式要求的数据库结构示意图，图片来自网络）
Q3：能否灵活自由地设计显示页面？
不同的企业、不同的用户都的使用习惯和审美风格具有差异化。即便面对同样的业务需求，客户对软件的页面呈现和交互也会有完全不同的要求。举例来说，客户A比较喜欢在页面的右上角寻找提交按钮；客户B可能习惯于提交按钮出现在页面的正下方，客户C则对提交按钮放到页面的右下角的设计更加青睐。于是我们需要为不同的客户做不同的页面布局，以缩减使用培训成本，提升用户的满意度。
类似的问题和解决方案，我相信您在多年的软件交付经验中已有体会。当然这里举例可能是冰山一角，客户对页面布局和样式风格的差异化要求远不止于此。如果您认可满足用户的使用习惯，适配公司的设计风格的重要性，那么请尽量选择支持灵活自由设计显示页面的低代码平台，以确保我们在项目开发和交付时不会陷入被动。
不同的企业、不同的用户都的使用习惯和审美风格具有差异化。即便面对同样的业务需求，客户对软件的页面呈现和交互也会有完全不同的要求。举例来说，客户A比较喜欢在页面的右上角寻找提交按钮；客户B可能习惯于提交按钮出现在页面的正下方，客户C则对提交按钮放到页面的右下角的设计更加青睐。于是我们需要为不同的客户做不同的页面布局，以缩减使用培训成本，提升用户的满意度。
类似的问题和解决方案，我相信您在多年的软件交付经验中已有体会。当然这里举例可能是冰山一角，客户对页面布局和样式风格的差异化要求远不止于此。如果您认可满足用户的使用习惯，适配公司的设计风格的重要性，那么请尽量选择支持灵活自由设计显示页面的低代码平台，以确保我们在项目开发和交付时不会陷入被动。
Q4：能否支持前后端分离的系统架构，后端复杂逻辑如何解决？
正如前面所说，软件行业发展了多年，沉淀出了很多最佳实践。与数据库设计范式类似的，还有前后端分离，数据库读写分离等等。上一点重点讲了前端，这里则要将目光转向后端。
在前后端分离架构的支撑下，不论是软件公司还是企业IT团队，在发展的过程中都会积累出自己的“核心数字资产”，这些资产往往表现在一些后台业务复杂逻辑计算方法（有的可能还会包含一些用于调优的“魔法数字”）。后台的逻辑复杂度高、技术积累价值大，相对较为稳定。如何用低代码实现后端复杂的业务逻辑，持续积累“核心数字资产”，是低代码平台必须解决的问题。在做技术评估时，千万别忘了这些运行在后台，没有任何界面的逻辑，因为这些才是系统和开发团队的核心竞争力。
（前后端分离，图片来自网络）
Q5：是否有全系统模块的解决方案？
在实际项目交付过程中，如果我们仅可以满足99%的需求，另外1%的需求满足不了，真实用户大概率是不会买单的。因此，在评估低代码产品的时候，我们一定要保证该平台可以支撑所有系统模块类型的开发，至少也要有足够的扩展性，可以确保使用纯代码开发出的模块能够与低代码模块进行无缝集成。
考虑到巨大的生产力差距，低代码平台覆盖的模块越多，整个项目的开发效率也会越高。那么，企业软件通常会涉及哪些类型的模块呢？我将其中最常见的列举如下：
- 多终端页面
- 可精确打印的报表
- 图表构成的可视化大屏
- 自动化任务
Q6：如何保证开发出应用的系统安全性？
安全性对任何一个系统都至关重要。使用低代码平台所开发出的应用中,绝大多数逻辑都是低代码开发者自行构建的，而不是出自低代码平台厂商。所以，我们很难通过平台的安全性报告来简单评判开发出应用的安全性，这就相当于没人关心Visual Studio和eclipse的安全报告一样。
这并不意味着我们不需要关心低代码平台自身的安全性。那么，我们该如何看待低代码平台的安全性，如何评估使用该平台开发出应用的安全性？以下几点值得参考：
-
该低代码平台是否有金融或者银行业的客户？这些行业一般对安全性要求比较高，他们能用一般行业肯定可以使用
-
在评估阶段，您可以基于该平台创建一个demo程序，并对这个demo做安全性检查，下面是一些安全检查的工具或者产品：ZAP – OWASP（免费）、SonarQube – SonarWorks（收费）、Burp Suite – PortSwigger（收费）、AppScan - IBM（收费）
（OWASP的ZAP检测工具，图片来自ZAP官网）
Q7：平台是否独立，能够不依赖其他第三方的产品?
这个点听上去有些奇怪，为什么会有低代码平台依赖特定的第三方产品？这就与国内低代码所处的发展阶段有关了。我来举两个例子：
-
有的产品说他是Excel的设计模式，但是其实他们所有的页面设计都是在Excel中，甚至访问时也是在Excel中访问，听起来没什么大问题，但是这其中有一个非常重要的点，Excel经常会更新Excel2008，Excel2010，Excel2016，….，这样每一次Excel升级，您都需要重新购买一次他们这个平台了；
-
有的低代码产品说自己是B/S架构，但是你必须安装他们特定的浏览器才能访问，这跟C/S架构的系统有什么区别？
为了确保后面的开发和部署过程可控，我推荐您优先选择独立的低代码平台。如果因为其他原因需要选择一款依赖特定的第三方软件，如数据库、Web服务器等的低代码平台，则需要将这些依赖的软件纳入部署清单和操作手册。
Q8：是否会产生新的“数据孤岛”？
数据孤岛这个概念从提出到现在，一直是企业信息化行业最希望解决的问题。作为新一代的软件开发技术，我们不需要使用低代码开发出来的应用成为新的数据孤岛。所以，不论是连接现有的数据库，还是支持通过Web API与其他软件互通，低代码都必须具有开放性，不能产生新的数据库孤岛。
跟进一步，如果该低代码平台可以帮助我们解决企业的数据孤岛问题，将多个系统打通，通过整合多源数据实现协同增效，那就更是一个加分项目了。
（数据孤岛现象，图片来自网络）
Q9：该平台的产品生态建设如何，是否有激励机制？
聚沙成塔，如果一个低代码产品选择孤军奋战，没有生态，大概率是不能长久的。对于低代码开发平台，生态的价值主要体现在以下两个方面：
- 模板：模板也叫开发成果，是指开发者使用低代码平台为特定行业或场景构建的“半成品”系统。基于半成品进行二次开发，可以进一步提升企业应用的构建速度。成熟的低代码平台通常具备模板市场，通过商务和技术手段，鼓励开发者将自己使用该平台开发出的应用放在市场中分享或销售，打造“人人为我，我为人人”的正向循环。
- 插件：低代码平台通常会开放插件机制，以吸引更多开发者封装自己开发的“模块”。插件和平台在一起运行，让低代码平台的应用场景更丰富。事实上，一家平台厂商的技术能力再强，也不能全部满足客户的所有需求。只有开放插件机制，建立插件付费环境，才能让广大的开发者都参于进来，共同打造更强大的平台。
低代码平台生态的关键在于如何建立长效激励机制，实现正向循环，通俗的理解就是让生态上游的开发者可以通过付费机制获得合理的回报。我们相信，只有提供长效激励机制的平台生态才能持久。
（多种连接器插件，图片来自Power Apps官网）
小结
在低代码平台的井喷期，使用者更应该擦亮眼睛，选择合适的平台产品，充分利用新技术带来的新价值、新动能。上面九个问题，就是我为您整理的低代码技术选型思路，希望能够帮正在评估低代码平台的软件公司和企业IT部门少走弯路，抓住时代潮流，开启低代码之旅。
