选择低代码产品时，一定要注意的问题？

选择低代码产品时，一定要注意的问题？

目前低代码正在风口，无数的低代码类产品活跃在市场中，乱花渐欲迷人眼；选择代码产品时到底需要关注那些点，才能让我们选到真正优秀的低代码产品，价格肯定也是选择的重要一环，但是这里笔者不会详细讨论；

选择低代码产品时，请仔细考虑并调查以下几个问题：

1) 产品所属的公司实力，是否对该产品有中长期的计划和投入？

如前所述，目前低代码在一个爆发期，夸张点说似乎没有一个低代码产品的公司都不意思说自己是一个软件公司，借此风向来抢一杯羹的大有人在，如果您选择了一个今几年刚创建的软件公司开发出来的低代码产品，或是您找了一家有历史的公司，但在他没有足够记得技术积累的情况下，就发布了低代码产品；那么先不说他们的产品如何，你肯定是小白鼠无疑了

2) 该产品的首次发布时间？

像我上一个问题说的那样，其实我们有一些很简单的问题，就能让我们不轻易的做别人的小白鼠，比如询问他们的发布时间。一般来说2015年以前，做低代码的那一定是因为做了详细的市场调研，足够的公司内部讨论以后确定开发的；2015年以后，低代码的大风已经开始，我们不能保证他是真的做了深思熟虑

3) 该产品是否能够支持协同开发，版本管理？

真正在落地一个项目的时候，难免遇到今天开发的功能，客户觉得没有用，但是过一段时间以后，发现此功能非常有用，又希望加回来，这个时候版本管理，回滚等等操作的作用就体现出来，这个有过一些代码经验的人一定深有体会；

即使很小的项目，协作开发也是非常必要的功能，除非是内部特别小验证的项目；这个我相信交付过项目的人应该是感同身受。

4) 能否支持高级数据库设计人员，自由设计规范完善的数据库结构？

数据库可以说是所有软件项目的地基，一般的项目，为了开发更加方便，扩展性更强，数据库的设计是非常重要的环节，二期功能但凡要修改数据结构的情况都是开发人员的噩梦。这个点无论是低代码还是纯代码，都是必要条件。

夸张点说，说数据库不重要的都是外行，在数据设计中最重要的是数据库第三范式的支持，我们不能说遵守数据库第三范式有多重要，但是我们能确定的是，不遵守第三范式，二期项目以后可能会有多痛苦，这个真的是不言而喻。

所以能否让开发者自由设计数据库结构，能否很好的实现数据库第三范式，对选择低代码开发平台直观重要。

5) 能否灵活自由的设计显示页面？

以客户为中心，这点华为任总已经详细的论证过并且出书了，这点相信大家也一定很认可；客户的需求经常是五花八门，他们对软件的使用习惯也是不同，举例来说客户A比较喜欢提交按钮放到一个页面的右上角，客户B可能习惯于将提交按钮放到页面的正下方，客户C可能喜欢将提交按钮放到页面的右下角，这样的页面布局我相信您在多年的软件交付经验中已有体会，当然这里举例可能是冰山一角，也许客户对页面的布局根本没有任何要求。

我们在选择一款低代码开发平台时，我们肯定要保证它能覆盖尽量多的场景，以确保我们在项目交付时不会被动。

6) 能否开发出前后端分离的系统架构？后端复杂逻辑如何解决？

正如前面所说，软件行业发展了多年，有很多相当优秀的经验：前后端分离，数据库读写分离，…等等，架构上的沉淀是其中的精华。低代码是软件行业发展的必然产物，取其精华弃其糟粕，方可基业长青。

每个公司在发展的过程中，都会积累出自己的核心竞争力，这些核心竞争力往往表现在一些后台业务复杂逻辑计算方法（有的可能还会包含一些魔法数字），这点从前端技术的不断变化（从JSP，H5；从js到jQuery再到现在VUE，React）但是后台语言却变化的很少也能侧面显示出来，前端展示只是表面，我们很容易就可以使用其他语言重新替换，但是后端的逻辑很多都是历史的经验沉淀。一个低代码平台也一定需要支持对后端复杂逻辑的开发保证您公司有核心竞争力。

因此，我们说支持前后端分离，支持完成后端复杂逻辑的开发对低代码平台的选项评估至关重要。

7) 是否有全系统模块的解决方案？如工作流，权限，报表，移动端等等

如果一个项目，使用低代码产品可以满足99%的需求，另外1%的需求满足不了，真实用户也是不会买单的，因此在选型低代码产品的时候，我们一定要保证所有软件的模块该低代码平台也是需要支持的，那一个低代码开发平台到底需要那些模块，这里以一个低代码平台举例，大致应有这么多个模块

如果支持这么多的模块就说明这个低代码平台就可以了吗？当然也不是，即使他有非常全面的模板，我们也不能单纯的认为他无所不能，不拍一万就怕万一，我们还需要了解万一有一些平台本身不能满足的功能，此时应该如何解决？答案是他们有没有丰富的前后端接口，万不得已时，我们能不能使用代码的老本行去解决这些问题；如果有接口那么我们认为这是一个可以满足我们需要的低代码平台。

8) 开发后的系统安全性如何保证？

安全性对任何一个系统都至关重要，再好的系统，安全性不能达标，无论谁都是不能接受的。但是其实对一个低代码平台来说，他们很难出一些安全性报告，这就相当于没人能给我Visual Studio和eclipse出一个安全报告一样，但是您使用他们开发的系统自然是很容易做安全认证，因此，这里有一个非常有用评判方式：

a) 该低代码产品有没有金融或者银行业的客户？这些行业一般对安全性要求比较高，他们能用一般行业肯定可以使用

b) 您可以使用一些第三方软件对这些低代码平台做出来的系统，做一下安全性的检查，如果你要谨慎的话，就把您做出来的系统做一下检查，如果觉得没有那么重要的话，你可以将该低代码产品的演示demo做一个安全性检查

9) 是否独立，不依赖其他第三方的产品?

这个点可能很多人是第一次听说，为什么会有这个考察点？举个例子：

a) 有的产品说他是Excel的设计模式，但是其实他们所有的页面设计都是在Excel中，甚至访问时也是在Excel中访问，听起来没什么大问题，但是这其中有一个非常重要的点，Excel经常会更新Excel2008，Excel2010，Excel2016，….，这样每一次Excel升级，您都需要重新购买一次他们这个平台了；

b) 有的低代码产品说自己是B/S架构，但是你必须安装他们特定的浏览器才能访问，这跟C/S架构的系统有什么区别？

我们要找一个低代码产品一定要找一个有独立产权，即使有使用第三方的软件也要让光明正大的用户知道他们都在使用那些第三方产品，并说明这些所有产品和该低代码产品的关系。

10) 不能产生新的“数据孤岛”，最好能解决现有“数据孤岛”的问题？

数据孤岛在前几年甚至现在也是一直软件行业的希望解决的问题，相信对数据孤岛你肯定不会很陌生，既然现在已经在解决数据孤岛，低代码肯定不能开发出来的系统会是一个新的数据孤岛，不管他是有现成的数据库可以直接连接还是支持webAPI被其他软件调用数据，他必须具有开放性，不能产生新的数据库孤岛。

如果该低代码产品可以帮助我们解决企业的数据孤岛问题，那可以给我们带更多的商机，更加值得您使用。

总结一下，一个低代码一定要有开放的数据接口可以被其他系统对接，最好同时还能对接别的系统的数据。

相信拿捏准这10个点，一定能在低代码选型时帮到你不少。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。