共计 10933 个字符，预计需要花费 28 分钟才能阅读完成。
按规定这篇应该叫做“数字技术名词解释—低代码”，但之前的名词解释篇都是一两天草就，这篇磨蹭了半个多月，七七八八写了过万字，于是做一把题目党。
低代码这个概念往年极火，争议也极大。有些人力捧，感觉当前“人人都是程序员”，又有不少人不屑一顾，如有 ERP 老兵讥讽《低代码，不要以比“中台”还快的速度臭大巷》，有 ThoughtWorks 中国某徐姓 CTO 训斥《“行业毒瘤”低代码》，还有很多认为低代码是新瓶装旧酒，早已有之，或者无非就是个高级外包。惋惜的是，无论反对还是鄙夷，各路专家写文都是“草就”，至今也没一篇三观正且详实的。阿朱的几篇三观是正，但行文也过于扼要，可能懂的天然懂，不懂的还是不懂。
本文心愿对这个以后动荡不安的畛域做一点“不草就”的综合阐明，想说分明七大问题：
- 低代码和无代码（也称零代码）是什么关系？
- 怎么判断一个低代码平台是否业余？
- 国内是否有业余的低代码平台？
- 低代码是不是新瓶装旧酒？
- 低代码真的搞不定业余的企业应用吗？
- 低代码不适宜开发哪些利用？
- 低代码并非银弹。
鉴于这个畛域当初切实太乱，心愿大家能多转发，让更多的人正确理解低代码。
一、低代码和无代码是两回事
第一步得把低代码和无代码分分明，因为这俩差别微小，但当初业界常常一概而论，导致很多很多问题，比方单方争执但指的不是同一个事件，厂商的口径乱，行业报告的后果不能看。
低代码专指低代码利用开发平台（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/…
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/blog…
无代码这个词通常用来形容一些细分畛域的开发工具，最常见的是利用搭建平台（国外个别叫 App Builder 之类），如国外的 Appy Pie、国内的宜搭、简道云等，还能够用来形容 Airtable / AppSheet / Treelab 这类在线表单工具或轻流这类的工作流工具。这几类工具差异微小，如下图所示，还有人将无代码和低代码的江湖分成十二个“门派”，由此可见无代码是一个相当宽泛的概念。
但无代码的“通用”开发平台，目前看并不存在，据我看未来也不会存在。因为开发软件必然要编写逻辑，就必然要写代码，除非哪一天人工智能能够做到主动写代码。
我感觉低代码和无代码的关系有点相似于关系数据库和 NoSQL。关系数据库专指一种特定的数据库，即使多家厂商的产品实现可能千差万别，但至多提供的性能很类似，都高度遵循 SQL 规范。
低代码开发平台尽管明天的标准化水平还没关系数据库这么高，但无论是 Gartner 还是 Forrester 都曾经开始给出比拟清晰的筛选规范，如要反对通用场景（如 UI、逻辑和数据三层都要有）、要满足业余开发需要等，随着行业倒退标准化水平必定会进一步提高。
NoSQL 则只有不是 SQL 都算，不论你是 KV、wide-column、文档还是图，都能够叫 NoSQL。NoSQL 这个词热了有几年，但当初不太讲了，因为市场格局开始清晰之后，大家就不会关注过于宽泛的 NoSQL，而是依据须要关注具体的类型。
我集体认为无代码这个词未来也一样会缓缓淡出，尽管当初十二个门派很是冷落，但不出几年真正有影响力的门派必定也不多，这时大家也就不关注无代码而是间接找具体的产品了。
本文后续只专一探讨面向通用利用开发的低代码。低代码不是一个想吸引业务用户的用语，业务人员见了“代码”两个字就吓跑了，再低也没用，如果业务人员写不了 100 行代码的话，那 10 行也一样写不了。
低代码平台次要面向业余开发，这点曾经是头部剖析机构的共识，尽管 Forrester 之前走过弯路，已经也公布过面向业务人员的低代码开发平台报告，但近两年曾经不再公布了，只保留面向业余开发者的低代码报告。
用户数据也阐明这一点，21CTO 在《低代码开发可不低，用户仍须要与 IT 技术部门联手》一文中提到据某统计“只有 6% 的低代码开发是由业务人员实现的”，OutSystems 的数据是 69% 的用户是业余开发，宜创科技 CEO 宜博也曾说低代码面临“懂技术的看不上，懂业务的学不会”的难堪。
所以无代码和低代码齐全不同：无代码面向业务人员，低代码面向开发人员；无代码泛指多种开发细分畛域利用的工具，低代码特指一种通用开发工具；无代码不被国内头部剖析机构认可，低代码被宽泛认可。
当初国内很多行业专家和剖析机构常常把两者一概而论，这对技术的价值掂量、甲方的技术布局和选型都造成很大凌乱，我迫切希望大家可能把低代码和无代码辨别开，集中钻研具备通用能力的低代码平台。
二、业余的低代码长啥样
当初市场上泥沙俱下号称“低代码”的产品很多，怎么能力疾速辨别是不是“业余”？很简略，找一个最业余的产品来对标。
哪个产品才是最业余的？咱们能够先看为什么低代码这两三年才热起来？不是因为 Salesforce 这样的 SaaS 厂商，也不是 Appian 这类 BPMS 厂商，这轮低代码热其实次要是因为 OutSystems。
OutSystems 尽管也早在 2001 年就成立，但之前始终“猥琐发育”，2018 年 D 融资了 $3.6 亿，才忽然引爆市场。无论 Forrester 还是 Gartner 都把 OutSystems 列入领导者象限，阿朱说他最推崇的低代码平台就四个，OutSystems 也是其中之一。所以，OutSystems 就是业余低代码平台的代表。
比照 OutSystems 和很多国内所谓的低代码平台，我找出了六项区分度最高的判断规范：模型驱动、可视化开发、表达式语言、软件工程、凋谢集成和脚本语言。
2.1 模型驱动
“模型驱动”可能是最显著的辨别标记，因为刚好有一个也很风行的概念叫“表单驱动”。很多人搞不清楚这两个概念，但其实这两类产品挺好辨别。
- 首先能够看用户手册，这样不必装置试用也能看出差异。应用模型驱动的平台比方 OutSystems、Mendix 的手册会有很大一章讲怎么做数据建模和解决，包含怎么定义实体、实体间关系、主键、唯一性、索引、数据怎么拜访、筛选、分组、统计等等，还提供 SQL 或相似扩大。应用表单驱动的产品则往往手册第一章就是阐明怎么定义各种表单，都是各种和界面相干的控件，比方单选多选下拉框、文本日期数字等。
- 其次能够看界面。下图是别离是模型驱动的 OutSystems 和某表单驱动产品的相干操作界面，大家看是不是很不一样。
（模型驱动，OutSystems）
（表单驱动）
2.2 可视化开发
可视化开发不是利落拽做个界面（这只能叫可视化设计），而是有残缺的可视化编程语言零碎，可能编写业务解决逻辑。看 OutSystems 这类产品的文档，你会发现很多编程语言的根本结构都有，比方程序 / 分支 / 循环 / continue / break、输入输出参数、局部变量 / 全局变量、struct 和 list、异样等。尽管这些货色都是利落拽实现，看上去没有稀稀拉拉的一行行代码来吓人，但也足以吓退业务人员。以下几张图都来自于 OutSystems，能够感受一下。
（左：逻辑开发工具箱，留神有 If、Switch、For Each 流程管制；右：一个比较简单的逻辑）
（怎么抛出和解决异样）
2.3 表达式语言
表达式语言有些相似 Excel 里的公式，有表达式语言才能够做一些比较复杂的计算。下图是 OutSystems 的表达式编辑器，能够看到有各种操作符，还有很多内置函数，比方数学函数、字符串处理函数等。
OutSystems 这个例子看起来还比较简单，但表达式语言也能够很简单。微软是搞语言的里手，下图是个微软 Power Fx 的例子，这个表达式是要提取一个句子最初一个单词的表达式，也挺简单吧（说实话我看了好大一阵子才看懂）。
表达式语言也有更平易近人的设计，比方轻舟就是用相似 Scratch 的积木块设计。两种设计性能上是等价的，积木块设计更容易上手，Power Fx 这样的设计写简单表达式更不便。
2.4 软件工程
业余的低代码平台须要提供测试、debug、版本控制等软件工程反对。开发软件都会出 bug（低代码平台根本打消了语法层面的 bug，但对语义层面的 bug 一样无能为力），需要也总是会变。所以测试、debug、版本控制这些反对也是必不可少的。OutSystems 为什么做得最好，我感觉跟它欠缺的 debug 反对是分不开的。下图是 OutSystems 的 debug 界面，看起来和业余 IDE 有一拼。
2.5 凋谢集成
实践上，有了模型驱动等上述四大性能，开发一个不是太简单的独立利用就够了，但典型的企业软件都是相互依赖和集成的，所以平台还须要具备可能调用内部 API 和凋谢 API 给他人的能力。平台如果没有这两方面的性能，开发进去的利用相互之间都没法连通和集成，全是技术债。咱们看国外对于低代码的文章，常常会看到一个词叫 Shadow IT，说的就是这个问题。大家都胡乱地开发各种利用，还都集成不起来，将是一场大灾难。
2.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 钻研、海比等也都出过剖析报告，但只有咱们对照上述规范就不难看出，尽管低代码舆论很是清静，但迄今为止应该说国内还很少有业余的低代码平台。
比方阿里往年始终宣扬的宜搭，声称是“低代码”利用搭建平台，但其实是一个“表单驱动”的“无代码”平台。阿里其实是打了个擦边球，说宜搭是“搭建”平台，没说是“开发”平台，你要说他适度宣传也算不上。但“搭建”和“开发”二字的差距可大了，“搭建”的意思是基于一些成熟模块组装利用，一旦遇到既有模块不够用的时候就歇菜。
国内很多剖析报告提及的产品大部分我都瞄过，但看一圈下来，集体认为也就 ClickPaaS 可能还够得上（我也不确定，因为 ClickPaaS 不凋谢用户手册，没深入研究），毕竟它有模型驱动和凋谢集成，其余的门槛都够不上。
这么凌乱的状态让咱们的 CIO 们可怎么办呢，这再次阐明如果不足无效的规范筛选真正业余的低代码平台，势必低代码和无代码一锅粥，后果大家都被搞得稀里糊涂。
四、低代码真的是新瓶装旧酒吗
对于低代码还有一种风行的观点是新瓶装旧酒，说二十年多年前的 Delphi、PowerBuiler（后称 PB）早就是低代码，但早就被时代淘汰了，明天的低代码也没戏。说这些话的大概率还是前辈。
要讲清楚这些问题得略微 digg 一点历史，当年的 Delphi 和 PB 可是神个别的存在，因为相比同时代的其余技术（比方诘屈聱牙的 MFC）来说易用性好太多，这俩不晓得做了多少企业信息化利用。顺手翻看一本《Delphi 开发典型模块大全》，外面尽是板材排料、进销存、文档治理、零售批发、房地产信息管理等案例。
这俩起初被时代淘汰，次要是因为时代变了，没跟上。互联网时代来了后，软件架构很快就从桌面端的 C / S 变成 Web 端的 B / S，再起初是挪动 App。Web 利用和 App 对前后端的要求比桌面利用都要高很多，因为大家做网页或 App 都是要吸引用户被动来拜访啊，不像桌面端的企业应用就算不好用你为了工作也得用。互联网的这二十年，技术栈倒退的越来越简单，新的低代码技术只能始终缓缓酝酿。
但 OutSystems 等厂商通过十多年的积攒，明天的低代码技术曾经远胜当年的 Delphi 和 PB。明天的低代码要“低”得多，当年的 Delph、PB 等如果按明天的规范，连入门的资格都没有。
咱们就以当年最风行的 Delphi 为例，Delphi 尽管号称“可视化编程语言”，但也就是实现了界面的可视化开发和数据库的 ORM，所有的逻辑都是要用代码写的，包含怎么把数据显示在表格也都要写代码。咱们说的六大规范里，头两位的模型驱动、可视化开发这些都没有。
PB 也就比 Delphi 稍好一点，它外围的 DataWindow 能够无需代码做出增删改查，算是迈入模型驱动的门槛，但它不反对实体关系，模型驱动能力并不残缺。同时 PowerBuilder 也没有可视化的逻辑开发，按明天的规范也只能在门槛彷徨。
贴两张老图让大家感受一下当年炸子鸡—Delphi。
（Delphi 的主界面，实现了用户界面的可视化设计）
（Delphi 的逻辑实现界面，得写代码）
士别三日当另眼相看，何况十多年。明天的低代码并不是新瓶装旧酒，而是新瓶新酒，里外都是新的。说新瓶是因为低代码这个概念是新的，说新酒是因为今日的 OutSystems 等业余低代码产品的能力曾经远超二十年前 PC 时代的 Delphi 和 PB。
我想说低代码是新瓶装旧酒的人啊，看到特斯拉也会说新瓶装旧酒，不还是汽车吗，看到 iPhone 也会说新瓶装旧酒，不就是个手机吗，我就打打电话，发发短信。这些人啊，可能也不因为别的，就是因为年纪太大了。
五、低代码能开发简单的企业应用吗
目前业界很多人认为低代码搞不定简单的企业应用。
如 ERP 老兵果总在《低代码，不要以比“中台”还快的速度臭大巷》一文中认为低代码只适宜用来做“简略的工作流和表单流转的利用”或“大型应用软件的性能延长的开发”，认为“不适宜开发简单逻辑的外围业务”。然而果总并没有说为什么。
“技术领导力”在《如何用低代码搞垮一家公司？》一文中认为低代码只适宜“翻新摸索类”、“生命周期短的”等利用。同样，也没有给出根据。
相似的舆论还很多，但都有一个共性，就是只说低代码不行，不解释，而且很多时候还把话说的那个斩钉截铁。很多人还真的把本人当回事啊。
企业应用听起来高大上，但其实几十年货色了，能有多简单呢？界面不必很时尚，不必扛百万并发，也没智能举荐啥的高级算法，其实从软件开发角度看企业应用是比较简单的。
企业应用的简单次要是畛域模型和业务流程比较复杂，但从前文咱们能够看到，低代码平台在建模和逻辑方面的能力都是比拟全面的，再通过脚本语言、凋谢集成等扩大机制，对于不不便低代码实现的中央，能够和业余代码开发合作实现。所以用低代码开发简单利用，实质上没问题。
这也不是我一个人的观点，明道云 CEO 任向晖写过一篇《APaaS 搞不定简单的利用，是这样吗？》，把企业应用的复杂性合成为数据、权限、流程、算法、集成、报表等六个维度，而后逐个给出解决方案。这才是捕风捉影的态度。我感觉任总的剖析曾经比拟充沛，我也不再开展说了。我置信任何人凡是不带偏见，深入分析的，都会发现企业应用并没有什么复杂性是低代码肯定搞不定的。
而且用低代码平台开发这类利用，还有不少独特劣势，如开发人员上手快（咱们的教训是个把月就能用得很溜了），开发效率高，便于业务人员和开发之间的沟通（因为逻辑大多是可视化的），不容易造成孤岛（因为业余的低代码平台默认就会依据模型生成 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…），能够看到 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 是面向游戏开发的，不在本文探讨范畴之内）。
- 头部互联网级利用：头部互联网利用用户量微小，为了优化性能有很多很多 trick，前后台技术架构非常复杂，低代码平台的实现是比拟规范的数据库 / 逻辑 / 界面三层架构，无奈满足性能需求。留神这不是说所有互联网利用都不适合，只是指那些用户量特大的头部利用。
- 剖析和智能化利用：剖析类利用天然应该用更业余的 BI 工具，智能化利用也应该用更业余的机器学习平台等工具。
- 系统软件、科学计算等其余专业性很强的利用。这个不多说了，预计也没谁想用低代码来做，但多说一句，尽管这些零碎的内核必定不适宜低代码开发，但界面可是很适宜，咱们轻舟低代码产品正是脱胎于云计算平台的界面开发。
当初大家应该能够发现很多业界风行的观点说低代码适宜这个那个的其实也都是错的，比方：
- 说低代码适宜“简略的工作流和表单流转的利用”：事实上业余的低代码并不见得特地适宜这类利用，比方 Gartner 就说 OutSystems 这方面的反对还不太好。其实最适宜这类利用的反而是那些“表单驱动”的产品，这些产品并非业余的低代码平台。业余的低代码平台搞这些也不是齐全不行，但属于大炮打蚊子，性价比不高。
- 说低代码适宜“生命周期短的利用”：事实上如果你用 OutSystems 这样“最业余”的低代码平台去做营销流动页这样“生命周期短的利用”，你必定会欲哭无泪。为什么？因为营销流动页对界面的要求很高哎。
- 说低代码适宜“创新型利用”：有篇文章按 Gartner 的办法把利用分成基础设施型（如 ERP）、差异化型（如 CRM）和创新型利用，说前两类利用低代码就别碰了，都是传统 IT 的菜，低代码就搞搞创新型利用，这个说法也不对。互联网 App 算典型的创新型利用吧，下面曾经说过这个低代码搞不定。
七、低代码不是银弹，不要适度神化
下面咱们说低代码很适宜开发典型的企业应用，长处显著，如开发人员上手快、开发效率高、增进沟通和集成等，但也不要认为低代码是银弹，用了什么问题都解决了。起因次要有以下三个方面。
- 开发工具只能解决软件研发的局部问题。
作为开发工具，低代码能够放慢在需要比拟明确时的软件交付，也能够在大方向比拟明确但具体需要不明时放慢软件的迭代更新。但企业应用和企业的经营治理形式、业务方向、业务流程、组织架构密切相关，和人密切相关，这些方面如果有问题，软件都不晓得怎么做，这都不是开发工具所能解决，该请征询还是得请征询。低代码就像特种兵，单兵作战能力是强，但如果将帅不行，战略战术拉垮，也打不了胜战。
低代码能晋升多少开发效率不足权威数据，不要有太高预期。
业界有很多对低代码开发效率的宣传，最多的是说什么晋升 10 倍啦，这些一看就是胡扯。一些厂商和剖析机构会公布提效数据，看似成果特地好，但因为后面说的无代码和低代码没分清问题，这些数据不可信。
比方阿里“宜搭”的数据说均匀将利用开发成本从 17.5 人天进步到 3.5 人天，提效 500%，但后面说过“宜搭”是无代码工具。无代码工具因为都是面向特定类型的利用高度优化的，提效显著很失常的，但不通用。
业余的低代码厂商如 OutSystems、Mendix，反而不敢宣传提效多少倍，所以一个厂商宣传的成果越好，就越不可能是业余的低代码平台。从咱们的教训看，用低代码做一些小零碎的确挺快，但上了规模后还能是不是有数倍晋升，我感觉也不大可能。依据咱们的初步教训，咱们感觉晋升 1 到 2 倍是一个比拟正当的预期。
- 行业典型的我的项目制限度了低代码的价值。
低代码平台因为可视化、效率高，最适宜业务和开发亲密沟通单干，疾速迭代。但以后甲乙方之间典型的我的项目制要求单方提前签订具体的合同和 SOW，这就把原本能够麻利开发的生生打回到瀑布模式，这样低代码疾速迭代的价值就很难体现。我的项目制存在太久，不是一时半会改的了的。
小结
最初做个小结：
- 无代码和低代码不是一个档次的概念。低代码是以 OutSystems、Mendix 等产品为代表，次要面向业余开发的通用利用开发平台；无代码则是一个营销用语，用于形容很多种面向业务人员的工具，如利用搭建、在线表单、工作流等。不存在无代码的通用利用开发平台。无代码这个概念过于宽泛，将来很可能会缓缓淡出市场。
- 要判断一个低代码平台是否业余，能够重点看模型驱动、可视化开发、表达式语言、软件工程、凋谢集成和脚本语言等六个方面。对照这些规范，不难看出迄今为止应该说国内还很少有业余的低代码平台，尽管舆论甚是清静。
- 业界对于低代码实用场景的观点大多数都是错的。比方业界很多人讲低代码搞不定简单的企业级利用，但都毫无根据。从技术原理登程，低代码其实最适宜做的就是企业应用，即使是 CRM、ERP 这样简单的利用；业界认为低代码适宜做“简略的工作流和表单流转的利用”、“生命周期短的利用”、“创新型利用”等观点也都是错的，这些利用很多恰好不适宜低代码。
- 低代码不适宜做的利用是对算法、界面、性能、剖析和智能化等专业性要求高的利用。
- 低代码对企业应用开发价值显著，但也不是银弹，不要适度神化。
对甲方来说，我认为 CIO 们应该从试点利用做起，通常来说要求本人的团队用低代码的阻力会很大，但能够要求乙方用低代码，降报价。
对乙方，我感觉短期很难卖平台，最好是和甲方谈个人力外包模式，防止我的项目制的僵化。业界说低代码是“高级外包”倒也没说错，尽管我感觉既然用的是低代码应该叫“低级外包”更适合😄。
最初的最初，我再次呐喊剖析机构可能辨别低代码和无代码，聚焦剖析面向通用利用开发的低代码开发平台，促成这个行业的认知对立，产品的标准化，这样才可能推动行业倒退。
无代码将死，低代码长存！
起源：冷技术热思考
作者：风轻扬
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
7 月每周四晚 8 点，【冬哥有话说】研发效力工具专场，公众号留言“研发效力”可获取地址
- 7 月 8 日，周文洋《微软 DevOps 工具链的 “ 爱恨情仇 ”（Azure DevOps）》
- 7 月 15 日，待定
- 7 月 22 日，张扬《基础设施即代码的⾃动化测试摸索》
- 7 月 29 日，胡贤彬《自动化测试，如何做到「攻防兼备」？》
