无代码和低代码

无代码和低代码完全不同，无代码面向业务人员，低代码面向开发人员；
无代码泛指多种开发细分领域应用的工具，低代码特指一种通用开发工具；
无代码不被国际头部分析机构认可，低代码被广泛认可。
把低代码和无代码区分开，集中研究具备通用能力的低代码平台。

专业的低代码长啥样

六项区分度最高的判断标准，有前四个就足以开发一个不太复杂的独立应用了：

  1. 模型驱动（和表单驱动截然不同）
  2. 可视化开发（如果只有拖拽只能叫可视化设计，应该包含了可视化编程语言系统）
  3. 表达式语言（又表达式语言才可以做比较复杂的计算）
  4. 软件工程（提供测试、debug、版本控制等）
  5. 开放集成（拥有调用外部API和开放API给别人的能力）
  6. 脚本语言（用编程语言做扩展）

    国内有专业的低代码平台吗

迄今为止应该说国内还很少有专业的低代码平台。
宜搭，宣称是“低代码”应用搭建平台，但其实是一个“表单驱动”的“无代码”平台。
但“搭建”和“开发”二字之差，差距可大了，“搭建”的意思是基于一些成熟模块组装应用，一旦遇到既有模块不够用的时候就歇菜。

低代码真的是新瓶装旧酒吗

当年最流行的Delphi为例，Delphi虽然号称“可视化编程语言”，但也就是实现了界面的可视化开发和数据库的ORM，所有的逻辑都是要用代码写的，包括怎么把数据显示在表格也都要写代码。我们说的六大标准里，头两位的模型驱动、可视化开发这些都没有。PB也就比Delphi稍好一点，它核心的DataWindow可以无需代码做出增删改查，算是迈入模型驱动的门槛，但它不支持实体关系，模型驱动能力并不完整。同时PowerBuilder也没有可视化的逻辑开发，按今天的标准也只能在门槛徘徊。

今天的低代码并不是新瓶装旧酒，而是新瓶新酒，里外都是新的。说新瓶是因为低代码这个概念是新的，说新酒是因为今日的OutSystems等专业低代码产品的能力已经远超二十年前PC时代的Delphi和PB。

低代码能开发复杂的企业应用吗

企业应用的复杂主要是领域模型和业务流程比较复杂，但从前文我们可以看到，低代码平台在建模和逻辑方面的能力都是比较全面的，再通过脚本语言、开放集成等扩展机制，对于不方便低代码实现的地方，可以和专业代码开发协作实现。所以用低代码开发复杂应用，本质上没问题。

目前用低代码开发复杂企业应用确实不多啊。没错，但我认为这只是时间问题。

  • 首先，低代码技术达到成熟状态的时间并不长
  • 其次，更重要的可能是非技术因素
    • 大部分企业对CRM、ERP的定制需求还没那么高，相比用低代码从头开发来说，采用Saleforce、SAP这样的套装软件实施，再做一些二次开发是更合适的选择。
    • 西门子会收购Mendix。另外ERP这样的企业软件实施强依赖咨询经验，这不是低代码能解决的，而业界有经验的咨询顾问显然更熟悉SAP这样的产品，也没有意愿改变。
    • 专业程序员对低代码抵触也非常大，好不容易练就一身武艺，用了低代码好像都没用了？业界越是宣传用低代码开发快多少倍，开发团队可能越抵触。

业界流行说低代码不能做CRM、ERP这类复杂的企业应用，这一说法很多人讲，但都没有根据。从技术原理出发，低代码最适合做的恰恰就是企业应用。目前用低代码做复杂企业级应用的case还不是很多，是因为低代码技术也就刚成熟不久、定制需求还不够强（套装软件能满足）或者行业不愿做，并不能说明它做不了。

低代码表面看似简单，其实是一个相当复杂的技术体系，背后涉及核心的编程语言层面的设计，比如DSL、类型系统、泛型等等，还有怎么diff、debug、undo，都不容易。另外低代码平台还需要不断追赶这20年变化极大的技术环境。20年前是C / S、.Net，后来流行B / S、Java，再后来又得搞App，操作系统从Windows变成Linux，现在又面临从SOA到微服务的转型。OutSystems的主任工程师Tiago Simões曾介绍过20年来OutSystems的发展（https://medium.com/outsystems-engineering/whats-not-new-in-outsystems-a-product-timeline-c781acd400cb#），可以看到OutSystems一边一直到补功能，直到2014年的9.0版本支持数据聚合处理才算比较完整，另一边一直在努力追赶技术趋势，直到2016年的10.0版本一口气推出Client-Side Logic、Local Storage、异步、Reactive等功能才算对移动App有较好的支持。这玩意是不做不知道，一做吓一跳，我们是做了轻舟低代码才知道这个东西很难。

低代码不适合开发哪些类型的应用

  • 对算法和复杂数据结构要求比较高的
  • 对界面要求特别高的
  • 头部互联网级应用
  • 分析和智能化应用
  • 系统软件、科学计算等其他专业性很强的应用

    低代码不是银弹，不要过度神化

很适合开发典型的企业应用，优点明显，如开发人员上手快、开发效率高、增进沟通和集成等

1）开发工具只能解决软件研发的部分问题。

企业应用和企业的经营管理方式、业务方向、业务流程、组织架构密切相关，和人密切相关，这些方面如果有问题，软件都不知道怎么做，这都不是开发工具所能解决，

2）低代码能提升多少开发效率缺乏权威数据，不要有太高预期。

阿里“宜搭”的数据说平均将应用开发成本从17.5人天提高到3.5人天，提效500%，但前面说过“宜搭”是无代码工具。无代码工具因为都是面向特定类型的应用高度优化的，提效明显很正常的，但不通用。专业的低代码厂商如OutSystems、Mendix，反而不敢宣传提效多少倍，所以一个厂商宣传的效果越好，就越不可能是专业的低代码平台。从我们的经验看，用低代码做一些小系统确实挺快，但上了规模后还能是不是有数倍提升，我觉得也不大可能。根据我们的初步经验，我们觉得提升1到2倍是一个比较合理的预期。

3）行业典型的项目制限制了低代码的价值。

当前甲乙方之间典型的项目制要求双方提前签订详细的合同和SOW，这就把本来可以敏捷开发的生生打回到瀑布模式，这样低代码快速迭代的价值就很难体现。

总结

  • 无代码和低代码不是一个层次的概念。低代码是以OutSystems、Mendix等产品为代表，主要面向专业开发的通用应用开发平台；无代码则是一个营销用语，用于形容很多种面向业务人员的工具，如应用搭建、在线表单、工作流等。不存在无代码的通用应用开发平台。无代码这个概念过于宽泛，未来很可能会慢慢淡出市场。
  • 要判断一个低代码平台是否专业，可以重点看模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言等六个方面。对照这些标准，不难看出迄今为止应该说国内还很少有专业的低代码平台，虽然舆论甚是喧嚣。
  • 业界关于低代码适用场景的观点大多数都是错的。比如业界很多人讲低代码搞不定复杂的企业级应用，但都毫无根据。从技术原理出发，低代码其实最适合做的就是企业应用，即便是CRM、ERP这样复杂的应用；业界认为低代码适合做“简单的工作流和表单流转的应用”、“生命周期短的应用”、“创新型应用”等观点也都是错的，这些应用很多恰恰不适合低代码。
  • 低代码不适合做的应用是对算法、界面、性能、分析和智能化等专业性要求高的应用。
  • 低代码对企业应用开发价值明显，但也不是银弹，不要过度神化。

CIO们应该从试点应用做起，通常来说要求自己的团队用低代码的阻力会很大，但可以要求乙方用低代码，降报价。对乙方，我觉得短期很难卖平台，最好是和甲方谈个人力外包模式，避免项目制的僵化。