低代码，要怎么低？和低代码有关的十大问题( 三 ) _低代码

文章插图

但在高级语言下就不需要这个了，因为高级语言下的代码可读性和这张图是一样的，但在复杂业务逻辑下用图形连线会很乱，对于熟悉看代码的开发者来说效率反而降低了，后来在《人月神话》20 周年纪念版里增加了这样一句话：

流程图是被吹捧得最过分的一种程序文档。详细逐一记录的流程图是一件令人生厌的事情，而且高级语言的出现使它显得陈旧过时。

所以这几种方法里我最倾向的是第 3 种，直接通过代码扩展功能，目前排名靠前的低代码平台都支持代码扩展，比如 Salesforce 和 ServiceNow，尤其是 ServiceNow 在前后端都使用 JavaScript，后端用到了 Rhino 引擎。
如果需求很常见，可以选择第 4 种方法，有些低代码平台针对某个垂直领域做了优化，集成了许多这个行业常见的功能，在同一个行业中，一家公司要解决的「根本任务」，在另一家公司大概率也会遇到，因此使用这种低代码平台可以明显降低成本。比如淘宝可以算是电商行业的「低代码」平台，它把各种电商相关的功能都集成进去了，同时还提供了店铺装修功能实现个性化设计。
低代码平台适合用在什么地方？什么样的应用适合使用低代码平台？目前看来最适合的场景是面向企业内部员工（B2E）的应用，也就是企业内部的各种系统及平台。
虽然也有面向对外应用的低代码平台，比如创建移动 APP，但这种只有小公司才会用，因为对外应用一般是公司主营业务，需要很高的自主可控性，而且定制需求多，对展现的要求也很高，没法复用低代码平台中的组件，只能通过自定义代码扩展，但如果大量使用代码扩展就还不如完全自己开发了。
以 jabdp为例，常用的功能，例如表单列表的增删改查，只需简单的自定义和配置就能自动生成。复杂的业务功能，只需要会基本的sql语句和javascript语法，就能进行快速开发，满足其个性化的业务需求，设计出各种复杂的企业web应用。既能快速提高开发效率，帮助公司节省人力成本，同时又有效解决企业级项目中常遇到的改需求的问题，不失灵活性。
jabdp开发平台适合用于大部分的企业级web应用的开发，尤其适合企业信息管理系统（MIS）、企业资源计划系统（ERP）、客户关系管理系统（CRM），业务支撑系统（BSS）等。并且就一些经典的项目案例提取整合出各种类型的项目模板，共享给开发者参考，开发者可以在原有的项目基础上进行修改定制，以打造其个性化的企业信息化平台。
低代码平台会带来什么新问题？尽管低代码平台能明显提升效率，但它也会带来新的问题，比如扩展性、难以支持复杂场景、性能等问题，但在我看来最大的问题是平台锁定，许多问题都是这点带来的：

平台使用自己内部独立的框架，需要额外的学习成本。
平台是个黑盒，不清楚内部如何实现，遇到 bug、性能等问题只能求助官方。
如果有的需求不能满足，需要等平台的排期升级。
信息分布在各处，不像本地代码那样方便全局搜索，对于不熟悉的新人往往得在各个界面里找半天，而且是功能越强大的平台越难找。
不方便多人协作，有的平台只提供少量环境，难以做复杂的分支管理。
平台后续发展是个未知数，哪天倒闭了怎么办？google 4 年前发布了一款低代码创建 APP 的产品 Google App Maker，既能可视化创建界面，又能写 JavaScript 扩展功能，但它在今年 2 月份的时候宣布关闭，无法导出，用户只能自己重写一个，连 Google 的低代码平台都会关闭，其它小公司就更别说了。

低代码平台为什么做不到开放？在我看来主要是两个原因：

技术上的矛盾，为了实现低代码就得隐藏很多不必要的细节，而这些细节有的依赖平台底层框架，有的依赖平台编辑器，这些都是低代码平台最核心的技术，没法开源。
商业上的矛盾，如果能方便导出，让使用者可以二次修改并部署到任意地方，低代码平台就变成离线开发工具了，只要一个帐号就能开发无数应用，不利于商业化，因此甚至有的低代码平台只提供 SaaS 版本，只能在线使用。

平台锁定这个问题在国内更严重，有种说法是古代中国属于大陆农业文明，农业文明的特点是强调自给自足，能不求人就不求人，这个长期影响很难改变，所以国内公司一变大就希望什么都自己掌握，信不过别人。