红帽白皮书新鲜出炉!点击获取,让你的云战略更胜一筹! 了解详情
写点什么

万字长文讲透低代码

  • 2021-07-06
  • 本文字数:9972 字

    阅读完需:约 33 分钟

万字长文讲透低代码

来源 | 授权转载自微信公众号“冷技术热思考”,经过不改变原意的删改


业界说低代码是“高级外包”倒也没说错,虽然我觉得既然用的是低代码应该叫“低级外包”更合适。


低代码这个概念今年极火,争议也极大。有些人力捧,觉得以后“人人都是程序员”,也有不少人嗤之以鼻,还有很多人认为低代码是新瓶装旧酒,早已有之,或者无非就是个高级外包。


本文希望对这个当前动荡不安的领域做一点“不草就”的综合说明,想说清楚七大问题:低代码和无代码(也称零代码)是什么关系、怎么判断一个低代码平台是否专业、国内是否有专业的低代码平台、低代码是不是新瓶装旧酒、低代码真的搞不定专业的企业应用吗、低代码不适合开发哪些应用、低代码是不是银弹。

 

本文对低代码相关的很多迷信和错误观点都做了比较客观的分析,希望能对促进这个行业的正确认知有帮助。

低代码和无代码是两回事

 

第一步得把低代码和无代码分清楚,因为这俩差异巨大,但现在业界经常混为一谈,导致很多很多问题,比如双方争论但指的不是同一个事情,厂商的口径乱,行业报告的结果不能看。

 

低代码专指低代码应用开发平台(LCAP),是一个被业界广泛认可的概念,头部的分析机构如 Forrester 和 Gartner 都已经发布了多年低代码开发平台的报告。如下图所示,大家可以看到这两家的报告入选的产品都很接近,特别是头部的六家简直是一模一样。这说明低代码应用开发平台已经是一个比较成熟的市场。



相反,分析机构对无代码的态度就很微妙了。虽然也有一些分析机构提无代码开发平台的概念,如 G2(当然更不用说目前混乱的国内分析机构),但 Forrester 和 Gartner 从未发布过无代码开发平台的报告。Forrester 和 Gartner 倒也不是说无代码是个伪概念,他们的共识是无代码这个词只是一个营销用语,主要用来突出一个工具无需编程基础,消除业务用户的恐惧。

 

‘No-code’ is a marketing term, implying the tool is for non-professional developers. — By Gartner


(来源:https://appian.com/resources/resource-center/analyst-reports/gartner-quick-answer-low-code-vs-no-code-dev-tools.html

 

Businesspeople hankering to deliver their own apps love the “no-code” message. Thus, “no-code” has become a marker for products aimed at empowering business users. However, customers report that even powerful low-code platforms in some cases can’t produce apps without any coding. So what does this mean for the “no-code” promise? — By Forrester


(来源:https://go.forrester.com/blogs/watch-your-language-low-code-and-no-code-are-not-the-same/


无代码这个词通常用来形容一些细分领域的开发工具,最常见的是应用搭建平台(国外一般叫 App Builder 之类),如国外的 Appy Pie、国内的宜搭、简道云等,还可以用来形容 Airtable / AppSheet 这类在线表单工具或轻流这类的工作流工具。这几类工具差别巨大,由此可见无代码是一个相当宽泛的概念。如下图所示,甚至还有人将无代码和低代码的江湖分成十二个“门派”。


(来源:https://pinver.medium.com/decoding-the-no-code-low-code-startup-universe-and-its-players-4b5e0221d58b


但无代码的“通用”开发平台,目前看并不存在。据我看将来也不会存在,因为开发软件必然要编写逻辑,就必然要写代码,除非哪一天人工智能能做到自动写代码。


我觉得低代码和无代码的关系有点类似于关系数据库和 NoSQL。关系数据库专指一种特定的数据库,即便多家厂商的产品实现可能千差万别,但至少提供的功能很相似,都高度遵循 SQL 标准。低代码开发平台虽然今天的标准化程度还没关系数据库这么高,但无论是 Gartner 还是 Forrester 都已经开始给出比较清晰的筛选标准,如要支持通用场景(如 UI、逻辑和数据三层都要有)、要满足专业开发需求等,随着行业发展标准化程度肯定会进一步提高。NoSQL 则只要不是 SQL 都算,不管你是 KV、wide-column、文档还是图,都可以叫 NoSQL。NoSQL 这个词热了有几年,但现在不太讲了,因为市场格局开始清晰之后,大家就不会关注过于宽泛的 NoSQL,而是根据需要关注具体的类型。我个人认为无代码这个词将来也一样会慢慢淡出,虽然现在十二个门派很是热闹,但不出几年真正有影响力的门派肯定也不多,这时大家也就不关注无代码而是直接找具体的产品了。


本文后续只专注讨论面向通用应用开发的低代码。低代码不是一个想吸引业务用户的用语,业务人员见了“代码”两个字就吓跑了,再低也没用,如果业务人员写不了 100 行代码的话,那 10 行也一样写不了。低代码平台主要面向专业开发,这点已经是头部分析机构的共识,虽然 Forrester 之前走过弯路,曾经也发布过面向业务人员的低代码开发平台报告,但近两年已经不再发布了,只保留面向专业开发者的低代码报告。用户数据也说明这一点,据Creatio调查统计,“只有 6%的低代码开发是由业务人员完成的”,而 OutSystems 的数据是 69%的用户是专业开发,宜创科技 CEO 宜博也曾说低代码面临“懂技术的看不上,懂业务的学不会”的尴尬。

 

所以无代码和低代码完全不同,无代码面向业务人员,低代码面向开发人员;无代码泛指多种开发细分领域应用的工具,低代码特指一种通用开发工具;无代码不被国际头部分析机构认可,低代码被广泛认可。

 

现在国内很多行业专家和分析机构经常把两者混为一谈,这对技术的价值衡量、甲方的技术规划和选型都造成很大混乱,我迫切希望大家能够把低代码和无代码区分开,集中研究具备通用能力的低代码平台。

专业的低代码长啥样

 

现在市场上鱼龙混杂号称“低代码”的产品很多,怎么才能快速区分是不是“专业”?很简单,找一个最专业的产品来对标。

 

哪个产品才是最专业的?我们可以先看为什么低代码这两三年才热起来?不是因为 Salesforce 这样的 SaaS 厂商,也不是 Appian 这类 BPMS 厂商,这轮低代码热其实主要是因为OutSystems。OutSystems 虽然也早在 2001 年就成立,但之前一直“猥琐发育”,2018 年 D 融资了 $3.6 亿,才突然引爆市场。无论 Forrester 还是 Gartner 都把 OutSystems 列入领导者象限,所以,OutSystems 就是专业低代码平台的代表。


对比 OutSystems 和很多国内所谓的低代码平台,我找出了六项区分度最高的判断标准:模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言。

 

(1)模型驱动


“模型驱动”可能是最明显的区分标志,因为刚好有一个也很流行的概念叫“表单驱动”。很多人搞不清楚这两个概念,但其实这两类产品挺好区分。

 

首先可以看用户手册,这样不用安装试用也能看出差别。使用模型驱动的平台比如 OutSystems、Mendix 的手册会有很大一章讲怎么做数据建模和处理,包括怎么定义实体、实体间关系、主键、唯一性、索引、数据怎么访问、筛选、分组、统计等等,还提供 SQL 或类似扩展。使用表单驱动的产品则往往手册第一章就是说明怎么定义各种表单,都是各种和界面相关的控件,比如单选多选下拉框、文本日期数字等。

 

其次可以看界面。下图是分别是模型驱动的 OutSystems 和某表单驱动产品的相关操作界面,大家看是不是很不一样。


(模型驱动,OutSystems)


(表单驱动)

 

(2)可视化开发


可视化开发不是拖拉拽做个界面(这只能叫可视化设计),而是要拖拉拽写处理逻辑。看 OutSystems 这类产品的文档,你会发现很多编程语言的基本构造都有,比如顺序 / 分支 / 循环 / continue / break、输入输出参数、局部变量 / 全局变量、struct 和 list、异常等。虽然这些东西都是拖拉拽完成,看上去没有密密麻麻的一行行代码来吓人,但也足以吓退业务人员。一下几张图都来自于 OutSystems,大家可以感受一下。


(左:逻辑开发工具箱,注意有 If、Switch、For Each 流程控制;右:一个比较简单的逻辑)


(怎么抛出和处理异常)

 

(3)表达式语言


表达式语言有些类似 Excel 里的公式,有表达式语言才可以做一些比较复杂的计算。下图是 OutSystems 的表达式编辑器,大家可以看到有各种操作符,还有很多内置函数,比如数学函数、字符串处理函数等。



OutSystems 这个例子看起来还比较简单,但表达式语言也可以很复杂。微软是搞语言的行家,下图是个微软 Power Fx 的例子,这个表达式是要提取一个句子最后一个单词的表达式,也挺复杂吧(说实话我看了好大一阵子才看懂)。



表达式语言也有更平易近人的设计,比如我们轻舟就是用类似 Scratch 的积木块设计。两种设计功能上是等价的,积木块设计更容易上手,Power Fx 这样的设计写复杂表达式更方便。

 

(4)软件工程


专业的低代码平台需要提供测试、debug、版本控制等软件工程支持。开发软件都会出 bug(低代码平台基本消除了语法层面的 bug,但对语义层面的 bug 一样无能为力),需求也总是会变。所以测试、debug、版本控制这些支持也是必不可少的。OutSystems 为什么做的最好,我觉得跟它完善的 debug 支持是分不开的。下图是 OutSystems 的 debug 界面,看起来和专业 IDE 有的一拼。



(5)开放集成


理论上,有了模型驱动等上述四大功能,开发一个不是太复杂的独立应用就够了,但典型的企业软件都是相互依赖和集成的,所以平台还需要具备能够调用外部 API 和开放 API 给别人的能力。平台如果没有这两方面的功能,开发出来的应用相互之间都没法连通和集成,全是技术债。我们看国外关于低代码的文章,经常会看到一个词叫 Shadow IT,说的就是这个问题。大家都胡乱的开发各种应用,还都集成不起来,将是一场大灾难。

 

(6)脚本语言


脚本语言就是用 JavaScripts、Python、Java 等做扩展,这些其实就是正儿八经的专业编程语言了,但低代码平台会把工程复杂性都封装好,让开发者不需要配置部署环境,随手就可以写代码,写完一键发布马上可以运行。

 

其实上述标准和 Gartner 是很一致的。Gartner 在魔力象限报告里说:


An LCAP is characterized by its use of model-driven or visual development paradigms supported by expression languages and possibly scripting…


里面模型驱动、可视化开发、表达式语言、脚本语言都提到了。

 

小结一下,判断是不是"专业”低代码,可以重点看模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言等六个方面

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


国内看似已经有很多低代码平台,道一云之前做个一个系列测评,T 研究、海比等也都出过分析报告,但只要我们对照上述标准就不难看出,虽然低代码舆论很是喧嚣,但迄今为止应该说国内还很少有专业的低代码平台。

 

比如国内存在一类平台叫“应用搭建平台”,这些平台有些标称无代码,有些标称低代码,但即便某些厂商标称的是低代码,其实基本上是采取“表单驱动”的设计。“搭建”和“开发”二字之差,差距其实非常大。应用“搭建”平台这个概念,在 Gartner 这样的国际顶级分析机构的字典里是没有的,和“开发”平台不在一个量级。所以,大家如果看到“搭建”平台,要特别留意,即便标称是低代码的,也好仔细的对照标准去评估一下,一般按前一节的标准,这些平台是够不上的。

 

国内分析报告提及的产品我都瞄过很多,但看一圈下来,个人认为八成都够不上专业低代码开发平台的门槛,目前我比较了解的也就 ClickPaaS 和 iVX 可能还够得上(我也不确定,因为 ClickPaaS 不开放用户手册,没深入研究),毕竟它有模型驱动和开放集成。

 

这么混乱的状态让我们的 CIO 们可怎么办呢,这再次说明如果缺乏有效的标准筛选真正专业的低代码平台,势必低代码和无代码一锅粥,结果大家都被搞得稀里糊涂。

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

 

关于低代码还有一种流行的观点是新瓶装旧酒,说二十年多年前的 Delphi、PowerBuilder(后称 PB)早就是低代码,但早就被时代淘汰了,今天的低代码也没戏。说这些话的大概率还是前辈。

 

要讲清楚这些问题得稍微 digg 一点历史,当年的 Delphi 和 PB 可是神一般的存在,因为相比同时代的其他技术(比如诘屈聱牙的 MFC)来说易用性好太多,这俩不知道做了不知道多少企业信息化应用。随手翻看一本《Delphi 开发典型模块大全》,里面尽是板材排料、进销存、文档管理、批发零售、房地产信息管理等案例。

 

这俩后来被时代淘汰,主要是因为时代变了,没跟上。互联网时代来了后,软件架构很快就从桌面端的 C / S 变成 Web 端的 B / S,再后来是移动 App。Web 应用和 App 对前后端的要求比桌面应用都要高很多,因为大家做网页或 App 都是要勾引用户主动来访问啊,不像桌面端的企业应用就算不好用你为了工作也得用。互联网的这个二十年,技术栈发展的越来越复杂,新的低代码技术只能一直慢慢酝酿。

 

但经过 OutSystems 等厂商经过十多年的积累,今天的低代码技术已经远胜当年的 Delphi 和 PB。今天的低代码要“低”的多,当年的 Delphi、PB 等如果按今天的标准,连入门的资格都没有。

 

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

 

贴两张老图让大家感受一下当年炸子鸡—Delphi。


(Delphi 的主界面,实现了用户界面的可视化设计)


(Delphi 的逻辑实现界面,得写代码)

 

士别三日当刮目相看,何况十多年。今天的低代码并不是新瓶装旧酒,而是新瓶新酒,里外都是新的。说新瓶是因为低代码这个概念是新的,说新酒是因为今日的 OutSystems 等专业低代码产品的能力已经远超二十年前 PC 时代的 Delphi 和 PB。

 

我想说低代码是新瓶装旧酒的人啊,看到特斯拉也会说新瓶装旧酒,不还是汽车吗,看到 iPhone 也会说新瓶装旧酒,不就是个手机吗,我就打打电话,发发短信。这些人啊,可能也不因为别的,可能就是因为年纪太大了。

 

关于低代码从 DOS 时代至今的发展脉络,阿朱在《低代码都快烂大街了,还有人在为低代码吵架》一文有详细介绍,感兴趣的可以看看。

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

 

目前业界很多人认为低代码搞不定复杂的企业应用。有人认为低代码只适合用来做“简单的工作流和表单流转的应用”或“大型应用软件的功能延伸的开发”,而“不适合开发复杂逻辑的核心业务”,但并没有说为什么。也有人认为低代码只适合“创新探索类”、“生命周期短的”等应用,但同样没有给出依据。类似的言论还很多,但都有一个共性,就是只说低代码不行,不解释,而且很多时候还把话说得斩钉截铁。


企业应用听起来高大上,但其实几十年东西了,能有多复杂呢?界面不用很时尚,不用扛百万并发,也没智能推荐啥的高级算法,其实从软件开发角度看企业应用是比较简单的。企业应用复杂主要是领域模型和业务流程比较复杂,但从前文我们可以看到,低代码平台在建模和逻辑方面的能力都是比较全面的,再通过脚本语言、开放集成等扩展机制,对于不方便低代码实现的地方,可以和专业代码开发协作实现。所以用低代码开发复杂应用,本质上没问题。


曾有文章把企业应用的复杂性分解为数据、权限、流程、算法、集成、报表等六个维度,然后逐一给出解决方案。这才是实事求是的态度。我相信任何人但凡不带偏见,深入分析的,都会发现企业应用并没有什么复杂性是低代码一定搞不定的。

 

而且用低代码平台开发这类应用,还有不少独特优势,如开发人员上手快(我们的经验是个把月就能用的很溜了),开发效率高,便于业务人员和开发之间的沟通(因为逻辑大多是可视化的),不容易形成孤岛(因为专业的低代码平台默认就会根据模型生成 API)。OutSystems 在其网站上特意强调:


OutSystems is well-equipped to build ERP and similar large, complex systems with the desired performance and scalability.


OutSystems 也有一些这方面的案例,做供应链、CRM、ERP 的都有。OutSystems 成立于 2001 年,那时候不开发企业应用开发什么呢?

 

但可能很多人会说,OutSystems 作为厂商当然这么宣扬,但目前用低代码开发复杂企业应用确实不多啊。没错,但我认为这只是时间问题。

 

首先,低代码技术达到成熟状态的时间并不长,即便是 OutSystems。OutSystems 虽然都成立 20 年了,但低代码表面看似简单,其实是一个相当复杂的技术体系,背后涉及核心的编程语言层面的设计,比如 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 有较好的支持。这玩意是不做不知道,一做吓一跳,我们是做了轻舟低代码才知道这个东西很难。

 

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

 

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

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

 

很多专家啊,不但错误的认为低代码搞不定复杂企业应用,还在低代码适合哪些类型的应用上也说错了。

 

主流低代码平台真正不太擅长的,是那些有各种特殊要求的应用,比如:


  • 对算法和复杂数据结构要求比较高的:我想不会有人想到用低代码平台去刷 LeetCode 题、打 ACM 比赛的吧。这里有个细微的地方是要区分是业务逻辑比较复杂还是算法逻辑比较复杂,业务逻辑复杂对低代码来说不是问题,算法逻辑复杂才是问题。那啥叫业务逻辑复杂呢,就是业务人员总之是说的清楚,或者是能理解的;啥叫算法逻辑复杂呢,就是业务人员只能给个目标,具体怎么实现是不管的,就算解释也是一脸闷逼的听不懂的。

  • 对界面要求特别高的:比如游戏或抖音、云音乐这样的社交娱乐型的应用。低代码平台可不擅长做酷炫的界面。(也有一些特定类型的低代码平台如 App Onboard 是面向游戏开发的,iVX 前端能力比较强,但都比较小众,不在本文讨论范围之内)

  • 头部互联网级应用:头部互联网应用用户量巨大,为了优化性能有很多很多 trick,前后台技术架构非常复杂,低代码平台的实现是比较标准的数据库 / 逻辑 / 界面三层架构,无法满足性能需求。注意这不是说所有互联网应用都不合适,只是指那些用户量特大的头部应用。

  • 分析和智能化应用:分析类应用自然应该用更专业的 BI 工具,智能化应用也应该用更专业的机器学习平台等工具。

  • 系统软件、科学计算等其他专业性很强的应用。这个不多说了,估计也没谁想用低代码来做,但多说一句,虽然这些系统的内核肯定不适合低代码开发,但界面可是很适合,我们轻舟低代码产品正是脱胎于云计算平台的界面开发。

 

现在大家应该可以发现很多业界流行的观点说低代码适合这个那个的其实也都是错的,比如:


  • 说低代码适合“简单的工作流和表单流转的应用”:事实上专业的低代码并不见得特别适合这类应用,比如 Gartner 就说 OutSystems 这方面的支持还不太好。其实最适合这类应用的反而是那些“表单驱动”的产品,这些产品并非专业的低代码平台。专业的低代码平台搞这些也不是完全不行,但属于大炮打蚊子,性价比不高。

  • 说低代码适合“生命周期短的应用”:事实上如果你用 OutSystems 这样“最专业”的低代码平台去做营销活动页这样“生命周期短的应用”,你肯定会欲哭无泪。为什么?因为营销活动页对界面的要求很高。

  • 说低代码适合“创新型应用”:有篇文章按 Gartner 的方法把应用分成基础设施型(如 ERP)、差异化型(如 CRM)和创新型应用,说前两类应用低代码就别碰了,都是传统 IT 的菜,低代码就搞搞创新型应用,这个说法也不对。互联网 App 算典型的创新型应用吧,上面已经说过这个低代码搞不定。

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

 

上面我们说低代码很适合开发典型的企业应用,优点明显,如开发人员上手快、开发效率高、增进沟通和集成等,但也不要认为低代码是银弹,用了什么问题都解决了。原因主要有以下三个方面。

 

1)开发工具只能解决软件研发的部分问题。作为开发工具,低代码可以加快在需求比较明确时的软件交付,也可以在大方向比较明确但具体需求不明时加快软件的迭代更新。但企业应用和企业的经营管理方式、业务方向、业务流程、组织架构密切相关,和人密切相关,这些方面如果有问题,软件都不知道怎么做,这都不是开发工具所能解决,该请咨询还是得请咨询。低代码就像特种兵,当兵作战能力是强,但如果将帅不行,战略战术拉垮,也打不了胜战。

 

2)低代码能提升多少开发效率缺乏权威数据,不要有太高预期。业界有很多对低代码开发效率的宣传,最多的是说什么提升 10 倍啦,这些一看就是胡扯。一些厂商和分析机构会发布提效数据,看似效果特别好,但因为前面说的无代码和低代码没分清,这些数据不可信。无代码工具因为都是面向特定类型的应用高度优化的,提效明显很正常的,但不通用。专业的低代码厂商如 OutSystems、Mendix,反而不敢宣传提效多少倍,所以一个厂商宣传的效果越好,就越不可能是专业的低代码平台。从我们的经验看,用低代码做一些小系统确实挺快,但上了规模后还能是不是有数倍提升,我觉得也不大可能。

 

3)行业典型的项目制限制了低代码的价值。低代码平台因为可视化、效率高,最适合业务和开发密切沟通合作,快速迭代。但当前甲乙方之间典型的项目制要求双方提前签订详细的合同和 SOW,这就把本来可以敏捷开发的生生打回到瀑布模式,这样低代码快速迭代的价值就很难体现。项目制存在太久,不是一时半会改的了的。

小结

 

最后做个小结:

  • 无代码和低代码不是一个层次的概念。低代码是以 OutSystems、Mendix 等产品为代表,主要面向专业开发的通用应用开发平台;无代码则是一个营销用语,用于形容很多种面向业务人员的工具,如应用搭建、在线表单、工作流等。不存在无代码的通用应用开发平台。

  • 要判断一个低代码平台是否专业,可以重点看模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言等六个方面。对照这些标准,不难看出迄今为止应该说国内还很少有专业的低代码平台,虽然舆论甚是喧嚣。

  • 业界关于低代码适用场景的观点大多数都是错的。比如业界很多人讲低代码搞不定复杂的企业级应用,但都毫无根据。从技术原理出发,低代码其实最适合做的就是企业应用,即便是 CRM、ERP 这样复杂的应用;业界认为低代码适合做“简单的工作流和表单流转的应用”、“生命周期短的应用”、“创新型应用”等观点也都是错的,这些应用很多恰恰不适合低代码。

  • 低代码不适合做的应用是对算法、界面、性能、分析和智能化等专业性要求高的应用。

  • 低代码对企业应用开发价值明显,但也不是银弹,不要过度神化。

 

对甲方来说,我认为 CIO 们应该从试点应用做起,通常来说要求自己的团队用低代码的阻力会很大,但可以要求乙方用低代码,降报价。对乙方,我觉得短期很难卖平台,最好是和甲方谈个人力外包模式,避免项目制的僵化。业界说低代码是“高级外包”倒也没说错,虽然我觉得既然用的是低代码应该叫“低级外包”更合适😄。


最后的最后,我再次呼吁分析机构能够区分低代码和无代码,聚焦分析面向通用应用开发的低代码开发平台,让产出的报告具备参考价值。


作者介绍:


汪源,网易副总裁、网易杭研院执行院长、网易数帆总经理,互联网技术委员会主席。2006 年获浙江大学计算机专业博士学位,是国内大型通用关系数据库内核技术最早的实践者之一。毕业后加入网易,长期主持网易杭州研究院技术研究工作,在国内最早开展分布式数据库、文件系统、搜索等大数据系统建设。现作为网易杭州研究院执行院长,全面负责网易集团基础设施/云原生/中间件/大数据/人工智能/信息安全/中台等核心技术平台建设、项目管理/用户体验与设计/运维保障/质量保障/创新服务等创新平台建设和网易数帆基础软件业务。

2021-07-06 14:5233032

评论 19 条评论

发布
用户头像
OutSystem这类产品我认为在国内不会有支持者,低代码不管是面向应用开发还是应用搭建,都是要有使用群体的,针对开发者,那么需要开放、组件丰富、可控,针对业务人员,需要门槛低、高效;OutSystem的门槛针对业务人员太高无法使用,针对开发者过于繁琐不可控。网易轻舟其实也是同样的逻辑,我认为不会有最终的受益群体,带来的结果是需要投入大量的研发成本,但是最终产品商业化一直在路上,但是有一个很好的商业模式,我个人比较认同的,面向开发者服务和收费,而不是最终应用的用户数收费。
2023-08-24 11:48 · 广东
回复
用户头像
最近公司上了个低代码平台,说业务人员也能用,看了2两天教程,真的上手试一下,用俩小时搭了个简单的图书管理系统,涉及到流程审批的地方求助了技术同事,还是挺好玩的,我们部门内部使用完全没问题,还能推送提醒!感觉只要了解业务流程、逻辑思维清晰,简单的应用自己就能搭建。感兴趣可以试一下,易鲸云https://www.yijingcloud.com/
2022-11-02 14:33 · 北京
回复
用户头像
企业级低代码还得看织信Informat:www.informat.cn
2022-06-27 14:34
回复
用户头像
给大家看下当前无代码平台都发展到什么程度了!有格https://www.iyouge.com/
2022-04-28 14:13
回复
有需要详细了解的可留言哦
2022-04-28 14:15
回复
用户头像
还是离不开表达式语言和脚本语言 离开这个复杂的就搞不定了,编程语言还是基础
2022-02-22 09:58
回复
用户头像
有些企业应用的表单交互很复杂啊,用低代码不好做
2022-01-03 15:31
回复
不是不好做,是低代码平台没有设计好
2022-01-08 23:20
回复
无远有一款表单号称世界最强,不妨用你说的复杂挑战一下
2022-02-08 23:51
回复
用户头像
表单也不一定不是非低代码的吧。能用就行,好用就可以持续维护。
2021-11-17 15:05
回复
用户头像
如果低代码还是给技术人员用的,我还是没理解低代码究竟要解决什么问题。
之前我理解的低代码其实是要先建立一些业务上和技术上的标准组件,然后低代码开发平台更多的是基于这些标准组建开发少量的胶水代码,所以才能说是低代码。本文没这要求,反而从模型驱动开始,又怎么达到“低”代码条件呢?
2021-09-27 20:41
回复
每家业务场景都不一样,你说的这种业务和技术上的标准组件哪来呢?定开而来的话又变成外包做项目了。如果业务场景高度类似,又可以买可配置的套装软件了。
2021-11-04 10:29
回复
用户头像
我反倒觉得的低代码才是低代码的未来。目前,阿里云,腾讯云,华为云都提供了基于表单式的一站式低代码开发服务,而且大多数针对ERP的低代码平台都提供表单式界面生成工具。对于界面构建表单式是最简便实用的途径。
2021-07-27 16:21
回复
赞成,低代码的本质是降本增效,表单驱动很适合当下企业的需求。低代码做得太细了,跟写代码有什么区别。
2022-01-05 21:54
回复
用户头像
.net 改改就能用了
2021-07-15 08:24
回复
用户头像
之前在企业内部做过几个模型驱动开发的项目(有一个UML模型驱动的, 也有一个使用Excel 做表单驱动的), 现在回想起来, 也勉强算是低代码开发平台吧, 不过当时都叫做MDA, 围绕着SOA展开的代码生成平台; 后来在Salesforce上开发过一阵子, 围绕着Salesforce也用过一些专门做REST API的低代码工具。
对比着低代码平台的六条标准, 感觉之前只是满足了模型驱动以及软件工程, 后面的可视化开发以及表达式语言,那真不是一个项目组能短时间搞定的; 而且之前都是围绕着SOA做项目制的开发, 缺乏cloud 支撑, 所以只能说是一个代码生成平台, 谈不上低代码平台。
  在使用低代码工具以及Salesforce的时候, 感觉低代码工具, 确实能解决企业的项目开发需求, 优势也就是像汪总所提到的; 但是对于一些稍微复杂的场景, 低代码工具解决起来就比较费劲, 例如有一个需求, 要求对一个API 所产生的XML进行解析, 根据需要去产生另外一些JSON输出; 但是这个XML 嵌套实在是太深了, 这就符合“复杂的数据结构”这一条了;这个时候低代码平台的缺点就展现出来了, 可以做, 但是写出来的代码没法看, 实在太复杂了, 除了作者之外,其他人根本看不懂, 遑论维护。
   
展开
2021-07-14 16:20
回复
用户头像
表单驱动的截图,您使用了明道云的一个早些时间的版本截图。
2021-07-11 19:43
回复
用户头像
网易低代码产品,即将上线--> https://www.163yun.com/product/lcap
2021-07-10 13:56
回复
用户头像
文章对低代码分析比较全面,不过按照文章分析的结果,低代码能适用的市场并不大,就看未来能不能夺取传统企业系统的市场了,个人感觉比较难
2021-07-06 17:57
回复
没有更多了
发现更多内容

加密算法是什么?有哪几种类型?有什么用?

行云管家

加密算法

有奖报名|StarRocks 获开源热力值增速第一,有你的贡献

StarRocks

数据库

旺链科技创始人刘涛荣登“中国区块链60人”榜单

旺链科技

区块链 数字经济 产业区块链 企业号十月PK榜

一文带你回顾操作系统的内存知识点

华为云开发者联盟

操作系统 开发 内存 华为云

房产|1-10月全国房地产开发投资数据解读

前嗅大数据

Ernie-SimCSE对比学习在内容反作弊上应用

百度Geek说

人工智能 AI技术 企业号十月 PK 榜

解析 RocketMQ 多样消费功能-消息过滤

阿里巴巴云原生

阿里云 RocketMQ 云原生

收藏|多指标时序预测方式及时序特征工程总结

云智慧AIOps社区

人工智能 机器学习 深度学习 时间序列 时间序列预测

单实例并发超1个亿!阿里云飞天洛神云网络NLB网络型负载均衡性能重大突破

云布道师

负载均衡 阿里云 云网络

【C语言】goto 关键字

謓泽

11月月更

特种设备如何管理?不同岗位视角职责解析

PreMaint

设备管理 特种设备

关于HTTPDNS,你知道多少?

移动研发平台EMAS

阿里云 网络 HTTP #EMAS

探知数字化研发4 - 底座篇

薛飞

数字化研发 数字化底座

打开时空隧道,重演云栖72小时云世界

阿里云视频云

阿里云 云栖大会

看完这篇线程、线程锁与线程池讲解,面试随便问!

小小怪下士

Java 程序员 面试 线程 线程池

DevOps 必备的 Kubernetes 安全清单

SEAL安全

Kubernetes DevOps 安全

初步探索GraalVM--云原生时代JVM黑科技

京东科技开发者

Java lua jdk 云原生 GraalVM

kubernetes下jenkins实战maven项目编译构建

程序员欣宸

DevOps jenkins 11月月更

HUAWEI DevEco Studio 3.1版本发布,配套ArkTS声明式开发全面升级

HarmonyOS开发者

HarmonyOS

房产|2022年10月房价数据出炉!房价上涨的城市仅有…

前嗅大数据

视频清晰度优化指南

得物技术

深度学习 算法 H.265 视频质量 图像超分

千万级学生管理系统设计试卷存储方案

Geek_92ba6f

IM通讯协议专题学习(二):快速理解Protobuf的背景、原理、使用、优缺点

JackJiang

DTSE Tech Talk | 第11期:深入浅出畅谈华为云低时延直播技术

华为云开发者联盟

云计算 后端 华为云

node.js的path路径模块和http模块

急需上岸的小谢

11月月更

HMS Core手语服务荣获2022中国互联网大会“特别推荐案例”:助力建设数字社会

HMS Core

手语 HMS Core

张文歆:思维需碰撞,才有更大的“火花”|对话 Doris

SelectDB

开源 职场 成长 学习路线 开源治理

Awesome MegEngineer 英雄招募帖,开源社区专属权益等你来领

MegEngineBot

深度学习 开源 MegEngine 开发者福利

洞见科技姚明:隐私计算行业将会发展为多层级多领域的数据智能流通网络

洞见科技

软件测试 | 接口自动化你不懂?听HttpRunner的作者怎么说

测试人

软件测试 自动化测试 接口测试 接口自动化 HttpRunner

软件测试校招面试题 | 实习生和应届生有什么区别?

测试人

面试 软件测试 自动化测试 测试开发 实习

万字长文讲透低代码_语言 & 开发_汪源_InfoQ精选文章