作为2021年技术类中的顶流，低代码的火爆并非空穴来风，根据IDC预测：“2024年将有65%的应用软件通过低代码开发。”

据企业网D1Net观察，将低代码用于软件开发的CIO不在少数，但是其中既有悲观者，也有乐观者，究竟CIO是如何看待低代码的，低代码选型过程中要注意哪些关键点，考虑哪些侧重点，又有哪些注意事项呢，接下来笔者将一一道来。

CIO眼中的低代码

低代码的优势显而易见，能够帮助企业降低开发人员的门槛，缩短应用开发时间，也能节约很多开发成本，大部分企业都已开始应用低代码敏捷开发技术。但是在实际应用的过程中，企业网D1Net发现，CIO们对低代码的态度各有不同，既有悲观者，也有乐观者。

CIO中的悲观者认为：低代码开发平台显得有些鸡肋，开发能力强的不需要，开发能力弱的即使用了也做不出功能完善的系统。低代码平台的初衷是抽象常用的CURD(增删改查)功能，降低开发门槛，但是随着周边生态的快速发展，缺点也逐渐显露出来——低代码平台的发展速度很难跟上周边技术日新月异的发展，覆盖实际生产中比较复杂和个性的应用场景，乍一看去很美丽，进入深水区以后就会发现到处都是坑。

这位CIO认为：目前来看低代码开发适配企业复杂的应用场景还是个伪命题。他建议企业用低代码自研应用时，要做好心里准备，好的结果是企业能接受项目后期的进度停滞，差的结果是项目推翻重构。即使拥有低代码开发源码，甚至自己可以更新低代码开发工具的功能，依然要面对2-3年后主流技术更新换代后要偿还的更新债务。

而乐观者认为：低代码和无代码对于研发效率的提升非常明显，已经有了大规模应用，而且案例越来越多。某公司研发负责人表示：“从开发人力来讲，低代码平台收益很明显，以前很多开发排期不允许的需求，现在可以自助解决，这是一个从0到1的突破。”

某公司CIO则直接表示：“公司培养二次开发人员，但是不会培养全栈开发，去从零开发一个系统。如果一定要开发自己的系统，一是这个系统在市面上找不到，二是可以用低代码平台开发完成。”

而喜茶数字化高级副总裁沈欣则在演讲中提到：“我们在系统选型时要求软件开发商自己要有自己的低代码环境：一是能提升响应速度，在业务部门的想法发生变化时能够尽快改正;二能降低我们的成本，因为低代码平台只需要进行灵活配置就可以了，一眼就能看出它用了多少工时，价格会非常透明。”

而理智的CIO则认为：低代码平台主要有两类应用场景，一是从0到0.5的场景，公司没有现成的系统，用低代码搭建，可以凑合用;二是快捷应用，例如调查问卷，要临时收集一些数据，上线快，修改快。然而，对于那些经典、复杂的应用，低代码平台恐怕难当大任，后期的瓶颈会越来越多，应尽量避坑。

低代码选型的六个要点

低代码平台在前期确实能让CIO们尝到诸多甜头，但是项目后期投入产出不成比例也是CIO们普遍担忧的。某低代码公司的CEO曾向企业网D1Net表示：“CIO们最担心的是低代码平台只实现了80%的功能就被迫停止，另外的20%无法实现，或是需要付出很高的代价，必须由原厂服务来完成剩余的项目。”

有了这样的担心，低代码平台的选型就显得至关重要了。目前低代码平台在中国尚无明确统一的行业标准，市场上的平台灵活性参差不齐，如何找到适合企业自身的平台对于CIO而言是一个非常大的挑战。

Gartner划定了低代码的四个特性：模型驱动、可视化开发、表达式语言、脚本语言。笔者认为，软件工程和开放集成也至关重要，这恰恰是中国企业需要的。

1)模型驱动。使用模型驱动的低代码平台，用户手册会讲怎么做数据建模和处理，包括怎么定义实体、实体间关系、主键、唯一性、索引、数据怎么访问、筛选、分组、统计等等，还提供SQL或类似扩展。

2)可视化开发。可视化开发不是拖拉拽做个界面，而是有完整的可视化编程语言系统，能够编写业务处理逻辑。

3)表达式语言。表达式语言有些类似Excel里的公式，例如各种操作符、内置函数，可以做一些比较复杂的计算。

4)脚本语言。脚本语言就是用JavaScripts、Python、Java等做扩展，也就是支持专业的编程语言。优秀的低代码平台会把工程复杂性封装好，而开发者无需配置和部署环境，写完代码一键发布就可以立即运行。

5)开放集成。企业软件是相互依赖和集成的，因此还需要具备能够调用外部API和开放API给别人的能力，这也是大多数CIO最关心的。低代码平台如果没有这两方面的功能，开发出来的应用相互之间无法连通和集成，必将成为技术债。

6)软件工程。软件开发都会出现bug，低代码平台基本消除了语法层面的bug，但对语义层面的bug无能为力，而且业务需求也在时刻变化，所以，测试、debug、版本控制这些支持必不可少。

有些CIO认为，Powerbuilder和Delphi也算低代码平台，但是有过5年Delphi开发经验的IT人告诉笔者，Delphi虽然实现了界面的可视化开发和数据库的ORM，依然要写很多Pascal代码，不仅包括逻辑代码，甚至把数据显示在表格里都要写代码，其根本原因在于Delphi不是模型驱动。

相比之下Powerbuilder比Delphi要好一些，无需代码就可以增删改查，但是不支持实体关系，模型驱动能力也并不完整，没有可视化的逻辑开发，因此这两种语言都逐渐没落。

实际上，今日的Mendix、OutSystems等专业的低代码产品的能力，已经远超二十年前PC时代的Delphi和Powerbuilder，并且也在逐渐提升人工智能和大数据方面的能力，这也是早期的产品所不具备的。

低代码选型中的五个侧重点

对于鱼龙混杂的低代码市场，前沈阳远大集团CIO张莹在接受企业网D1Net采访时表示：“很多低代码敏捷开发平台给的也是表单和工作流，但实际上是在偷换概念。真正的低代码敏捷开发平台，控件要足，数据支撑要足够多元化，要具备自主的ESB总线，要能与其他系统打通。”

张莹认为低代码平台的出现，就是为了在企业应用ERP、MES、WMS、CRM、SRM等专业软件时，弥补上游或下游之间的承接关系，因此更要有集成的概念。他强调：敏捷开发也需要上层信息化战略规划的支撑，需要界定BPM、ERP、WMS等各个软件之间的界限，不能越界，这一点尤其重要。如果今天做个审批，明天做个流程，那就是头痛医头脚痛医脚了，对于CIO来说这是大忌。

在张莹看来，国内和国外的低代码平台各有千秋，侧重点各有不同。国外的低代码平台确实十分强大，但是更是一种纯粹的开发工具，减少了用Java或.net在底层写代码的工作量，但是其受众人群是架构师或专业开发人员，而中国用户期望的低代码平台是快速实现，不需要专业的开发人员查bug、做注释、写语句等等基础性的开发工作。

实际上，低代码平台对于一个企业而言，并不是一道单选题，而是多选题，侧重点不同，选择的平台自然不同，这也是低代码产品市场百花齐放的原因。

如果企业要统计年会服装尺码，统计哪些员工打了疫苗，这类用后就会丢弃的工具，OA或IM内置的无代码工具就可以灵活实现。因此，要实现用后弃之的表单型功能，可以选择OA或IM里的无代码工具。

如果企业在信息化基础层面并没有那么扎实，侧重点在于如何把流程和逻辑梳理清楚，而表单和实现只是第二个侧重点，那么选择炎黄盈动、易正等BPM类的低代码平台和工具可能更合适。

如果企业想选择某些特定的业务软件，需求灵活度高，表单之间有很强的关联关系，数据量又很大，可以选择那些拥有低代码开发环境的软件开发商，提升企业IT的响应速度，并降低研发成本。

如果企业要开发复杂应用，且市面上没有成熟的产品，那么就需要参考上述六个低代码选型要点，对国内外的低代码平台进行综合评估，并且要结合这些平台积累的企业所在行业的Knowhow，因为拥有行业Knowhow的低代码平台已经拥有现成的模型，因此开发速度的提升可能不止几倍，而是几十倍，会更具优势。

如果企业内部是基于Excel的管理体系，受限于Excel的分发模式，安全系数低，需求的灵活度不高，差异性大等因素，而且随着业务的发展越来越复杂，那么选型时可以选择那些支持私有化部署的低代码平台，并且将其纳入IT管控，作为业务数字化的重要手段，为业务部门提供高效的IT支持。

警惕低代码平台壁垒

为了推进低代码，喜茶数字化高级副总裁沈欣先后与20余个低代码供应商进行深入交流。在他看来，各家产品的技术代差并不大，也就6-8个月左右的技术差异，很快就能追赶上来，因此CIO们在选型时不必太过担心。

沈欣强调：低代码的关键壁垒在于应用的增值维度，这些厂商可能会通过打深、打通自身的核心生态来形成一些业务壁垒。例如A厂商打通了一个地图软件、支付软件、IM软件，那么用A的低代码平台可以非常简单的将这些功能集成进来，但是用B或C的地图、支付或IM软件，要么不行，要么会花费很大代价，这是沈欣在选择系统时遇到的最大的壁垒。

除此之外，沈欣提到，专业的程序员写出来的代码依然会存在bug，如果让那些没有太多开发经验的入门级开发者做开发，低代码平台首先需要更强大的自动测试工具，还需要更加轻量级的DevOps体系，只有足够灵活，才能不影响业务的开发。此外，高度灵活的低代码平台开发出的系统，还有可能面临数据合规的问题，尤其是那些即将上市的企业，必须考虑到这一点。

最后是低代码的文档管理，很多企业在进行低代码开发时往往会忽略这一问题，这恰恰是低代码无法推进下去的直接原因，因为后期介入的开发者可能完全不知道之前的开发者到底做了哪些功能，因此，低代码选型也需要考虑文档管理的问题。