2019年开始，低代码爆火。有人认为它是第四代编程语言，有人认为它是开发模式的颠覆，也有人认为是企业管理模式的变革……有很多声音，社区讨论很热烈。CSDN随后展开低代码平台产品系列活动，包括低代码开发者认知度与应用线上调研，市场洞察报告，专家专访专辑，研讨会等。邀请低代码平台产品的各个角色共同研讨，力求为大家呈现一个立体的、透光的低代码发展脉络和未来趋势。
本期访谈嘉宾：宁伟，CSDN知名博主。葡萄城产品市场总监，2005年加入葡萄城，从事.NET平台软件开发和项目管理工作，2018年起专注于活字格低代码平台的市场运营与推广。
谈国内外低代码平台产品的发展脉络
CSDN: 您怎么看待2019年这个时间点？低代码目前真实的现状是怎样的？
宁伟： 事实上2014年开始，一些传统的软件开发工具厂商或者说主流的ToB风格的玩家已经纷纷入场研究低代码了。葡萄城2012年启动活字格的研究和开发，2016年就发布了活字格低代码开发平台。从一些行业研究机构的报告上看，现在市面上活跃的低代码平台厂商，除了一些互联网巨头在2019年入场之外，几乎全都是2015年到2019年这段时间就已经入场开始产品布局的。也就是说低代码，从2014年Forrester发布了低代码的概念之后就一直存在了。
但是，2019年开始到今年，随着风险投资的进场，这个概念突然之间爆火起来。是资本催生了低代码的火爆，它的产品定义边界也一直在演进。现在这个时间点在探讨低代码这个问题的时候，就需要去分时间阶段的去看了。但整体上来讲，在2019年风口起来之前就在入场的玩家，事实上是构成了目前中国低代码行业的主力。
CSDN：目前要想定义清楚什么是低代码，需要先为低代码分类，国内外的低代码平台产品，他们的用户群，产品定位其实都不尽相同，纵观国内外的低代码厂商，目前比较清晰的分类有哪些？
宁伟：刚才我们聊了国内的大概情况，那么国外的其实也是有一些比较有意思的事情。低代码概念在国外火起来，也是来自资本的助力。2018年Outsystems拿了3.6亿美元的投资，估值达到超十亿美金这种量级的，是当年的独角兽。Outsystems是一家在葡萄牙的公司，总部在里斯本，开发团队大概两三百人。因为Outsystemss也是葡萄城开发控件的客户，我们对这家公司的了解也比较深一些。他的发展历程也可以帮助我们了解欧美在低代码方面的发展历程。
服务专业开发者的低代码平台
以Outsystems为代表的国外主流低代码开发平台，它的产品开发工具的属性，相比国内很多产品会更加纯粹一些。举个例子，Outsystems起步时，它所面对的用户群体就是专业开发者。它的产品几乎所有的设计全都采用了现有的软件开发体系，包括模型驱动、前后端分离、包括构建外部API，以及调用第三方接口的做法等。包括在部署阶段，整个流程都是按照一个专业开发者的专业开发工具的标准去做的。即便是部署也是私有化部署为主，在他的云端所采用的方式，跟很多人想的云端部署也不太一样。
通常意义上讲的云服务，SaaS服务一般情况下来讲叫共享资源，是多租户模式。也就是大家很多人去共享同一个云主机，用同样一套资源来实现，通过错峰使用时间，来实现资源的高效利用，这是云基本的底层逻辑，但是Outsystems在做这件事情的时候不一样。
他们提供了独占式的云服务模式。简单理解就是说Outsystems的云上部署，后台相当于给你创建了独立的属于你的一台虚拟机。资源是独占的，不会出现资源争抢。当然这样子来做，对于云服务商来讲，它的成本是很高的。但当客户把核心系统或者业务系统用低代码的方式开发部署后，考虑到对处理能力和可用性的高要求，是更加希望它能够独享资源部署的。
这种服务于企业核心业务的底层逻辑并不是Outsystems的专利，国外的Mendix和国内的活字格、ClickPaaS等都是这个赛道下的典型玩家。只是有些厂商更偏重于提升产品作为开发工具的技术能力，将低代码平台作为一个独立的产品进行销售；另一些厂商投入更大的力量在自己组建实施团队为客户做交付而已。本质上，这些都是面向专业开发者的低代码平台。
需要注意的是，这里的专业开发者和程序员其实不完全划等号。按照Gartner关于平民开发者和专业开发者的划分，凡是向IT部门汇报的开发者都是专业开发者，而向业务部门汇报的开发者则是平民开发者。两者的差异主要体现在工作职责和岗位划分，而不是技术能力。所以，不管是Outsystems还是活字格，使用者中都不乏在企业IT部门中从事低代码开发的初级技术人员，这些人与程序员配合，前者负责简单的增删改查和页面设计，后者则更关注系统架构、数据库设计以及编程扩展等高技术含量的部分。
Outsystems：轻应用场景的低代码平台
据我对国内市场的了解，面向专业开发者的低代码平台在体量上并不占优势。在资本的牵引下，国内的大多数低代码平台在向互联网轻应用场景的平台模式发展，从应用场景到技术路线，和前面提到的面向专业开发者的低代码平台存在很大的差异。
轻应用场景，在企业中它并不是核心业务场景。比如在生产制造型企业，一个轻应用场景举个例子，比如做一张厂商宣传海报，做一个疫情流调的填报等等，能够快速上线，让大家来填写提交的。以此为例，工厂比如说有1000个人，1000个人就都是低代码开发平台最终辐射到的用户群体。
而另外一个方面，软件公司或者企业IT部门使用面向专业开发者的低代码平台，来实现核心系统应用，比如生产系统，库存系统。料库和成品库之间库存流转，然后做财务的成本核算，业务财务一体化结算等等，这些核心业务的话，那它的使用群体的用户数量，其实是很小的。一个企业的1000人中可能只有不到100个人在使用。对于互联网公司和投资机构来讲，10倍的用户群体差异意味着质的差别。微信搜索readdot，关注后回复编程资源获取23种精品资料
所以，在互联网投融资的支持下，国内更多厂商走上了面向轻应用，快速过大用户群体的路线，并取得了动辄上亿的融资回报。从另一个角度上看，用户群体的规模就决定了中国低代码平台的辐射面，影响到的人肯定是要比欧美更广泛的。
其实，这类低代码平台产品也可以理解为是无代码平台产品，Forrester称这种为LCDP for business developers，与前面将的LCDP for professional developers对应。在资本市场的支持之下，我们相信无代码会从低代码中进一步分化。无代码很快会成为一个新的分支独立出去。因为这一些类型的产品，它的商业逻辑是固定的。那就是拥有更大的用户群体，更大的流量入口机会，更多的投融资，让更多人知道，然后上市变现，这是互联网企业中一个非常典型的路径，与软件开发工具类厂商的底层逻辑完全不同。
降低二次开发成本的低代码平台
低代码除了上面这两种定位之外，还有一种类型的典型应用就是二次开发。对于企业级软件来讲，CRM也好，ERP也好，它通常不是买回来就能用的。需要一个团队来进行二次开发，适配企业独特的个性化需求。这个对于大部分企业软件来讲是逃不过去的，甚至可以说是占到很大比例的。所以每一个做CRM，做ERP的厂商，他必须要考虑一个问题，怎么样帮助我的实施团队，以及我的商业伙伴，我的代理商的实施团队，去快速的搞定二次开发这件事。但是，在低代码出现之前，二次开发是需要靠编程的方式来实现的，而且必须用主系统规定的语言和类库，推广起来难度很大。
低代码的概念提出后，很多的CRM、ERP厂商第一时间开始琢磨低代码做二次开发这个方向。Salesforce、微软Dynamic以及国内的用友和金蝶也都是基于类似这样的背景提出的低代码平台。帮助行业软件快速完成二次开发，本身是一个非常典型的企业个性化应用场景。而且，参与这部分实施的开发者，整体技术水平、技术能力是比厂商侧的研发人员低的，低代码的引入会为他们带来更多的可能性。
所以二次开发的工具也在逐步迭代和升级，现在我们看到的低代码开发平台Lighting、PowerApps、YonBIP等就是不断让二次开发变成了一个更低成本的事情。但是这也滋生出一个问题就是，在不同平台下的低代码开发工具所生成的系统依然要围绕着主系统运转，他们之间是非常割裂的。这就会给后续的系统间扩展，复用，移植等很多方面带来障碍。
上面提到的三个类别并不能覆盖所有低代码产品，Forrester在报告中甚至给中国的低代码厂商划分出了9大类别。低代码平台的多样性很强，初次看到“低代码”时，人们很容易产生盲人摸象的感觉。这也是目前大家对低代码的意见存在较大分歧的主要原因。所以，如果你真的想要了解这个行业，在迷雾中找到一条路，还是得根据自己团队的技术能力、需要面对的应用场景选择合适的类型入手。如果你是一个程序员，要开发核心的生产和销售软件，却将轻应用低代码平台作为评估低代码技术的唯一选项，我相信你无疑会对低代码很失望；但是，如果你选择了服务专业开发者的活字格，结论很可能是相反的。不要以为这是个玩笑般的比喻，我们的售前技术支持团队反馈说有不少程序员都走了这个弯路。
CSDN：如果要给开发者一把尺子，去衡量这个产品是否真的适合自己，从开发效率，技能提升，或者稳定性等等方面，获得一个对低代码平台产品相对全面的评估。只用三个问题来判断，你会如何选择？
宁伟：这是一个方法论的问题。我认为应该用这三个问题来判断：
1. “拿来干什么”。不同类型的低代码产品有不同的应用边界和底层逻辑。开发者评估一款低代码产品时，首先弄清自己的应用场景。如果你希望做的是简单的轻应用，讲究短平快，不需要考虑和其他软件集成以及持续发展的问题，那么选择面向专业开发者的低代码平台的话，学习成本就太高了；如果你希望用低代码技术开发核心业务系统甚至分阶段搞定全公司所有软件开发，轻应用平台显然无法承载你的梦想。
2. “怎么干”。同样的应用场景，不同的产品有不同的实现路径。条条大路通罗马，但是高速公路需要掏过路费，乡村小道跑的不舒服。具体到开发工具上，我们需要根据自己的技术能力选择更适合自己的低代码平台。不过，如果有学习的意愿和投入，我建议选择架构更专业、开放性更高、与大学里软件开发课程更近的那一款，提升一下软件开发的上限。
3. “谁干成了”。实践是检验真理的唯一标准。如果我们没有足够的时间来做详细的评估，可以去看一下其他人用该平台开发的系统，从界面自由度、功能复杂度到稳定性，都能体现到案例中。比如如果一个平台有大量开发ERP、MES这种核心系统的案例，客户的要求会比做后勤部门数据填报的轻应用高很多，所以该平台的稳定性应该没问题。所以，去这些低代码平台厂商的官网看看他们推的案例，也是一个不错的方法。
CSDN：程序员喜欢的低代码平台产品要具备什么样的特点
宁伟：对于程序员来说，转型到低代码开发和新学一门编程语言在本质是一样的，必须考虑学习的成本和之前经验积累的复用性。所以，我们接触过的大多数程序员在做低代码平台选型评估时，首先会看这个工具用起来，跟之前写代码的流程一样吗？跟写代码的架构一样吗？为啥？因为这样程序员和其他技术性岗位一样，专业知识，专业技能是需要持续积累和复用的，只有这样才能让职业生涯走得更顺。所以，我们不能让程序员之前一行一行写代码，积攒起来的经验，在切换到低代码平台开发之后，全部作废。如果做不到这一点，大多数程序员就会被推到了低代码的对立面。
程序员在选择开发工具的时候希望能继续延续自己的优势，逆势而为就会为产品的落地造成很大的障碍。顺势而为就可以延续程序员之前积攒的经验，成为更好的开发者。
落实到具体功能上面，我们之前做过一次调研，面向活字格低代码平台的用户群体，征集开发者最喜欢的三个功能是什么。最终，我们整理出三个点，现在看也是比较有代表性的。
第一个是：抹平数据库之间的差异性，自动适配MySQL、MS SQL Server、Oracle的数据类型和特殊语法，学习成本更低。
第二个是：可以在开发中对服务端API可以调试，并且提供包含各步骤耗时在内的详细日志。让低代码不再是一个黑盒子，Debug非常方便。这里多说几句，在核心业务系统中业务逻辑一般会很复杂，哪怕最简单的一个库存出库，也并不是说创建一张出库单就完了。实际的业务流程中除了出库单，还要更新库存数据，做设置好的低库存检测，触发警报的同时，调用采购系统的接口发起补货流程，最后更新财务使用的库存数据等等。这一系列操作都需要确保事务性和处理性能。事实上，我们很难确保一次性将这些操作全部搞正确，低代码平台能提供快速定位和修复问题的能力变得非常重要。
第三个是：前端布局可以自由修改。有很多的低代码开发平台的产品，压根不允许你自己布局，对UI要求高的客户来说，这种方案来说就非常不友好了。
从上面的这些内容可以看到，程序员最关心的功能是什么？第一就是一定要能操作数据库，第二是一定要能像写程序一样去精确的控制业务逻辑，第三就是一定要自由的做布局。说到底，一个前后端分离的企业软件，就这三件事。
