ITPUB专访 | 低代码的前世今生

从2014年Forrester明确提出低代码的概念以来，经过八年的发展，低代码领域基本已经有了成熟的发展，而具体到国内市场，低代码开发自2018年之后就逐渐受到越来越多的关注。尤其2020年疫情之后，已然成为了IT行业一时爆火的风口，同时，对低代码的争议也越来越多。

主流的声音认为，低代码理论上存在的开发门槛低、易用性等特点，能够满足企业在数字化转型中大量需求，这也是低代码迅速成为to B风口的一个关键因素。但持相反论调的人则声称，低代码是“新瓶装旧酒”，他们质疑低代码是伪需求，同时认为低代码平台暗藏巨大的变革成本。

本期我们有幸采访了低代码方向的专家宁伟老师，一起探讨低代码是什么、低代码可以解决什么问题、如何组建低代码开发团队等问题，理解低代码的前世今生。

问题1：您好，宁老师！很荣幸有机会采访到您，先简单介绍一下您自己！

我叫宁伟，2005年毕业于西安交通大学，随后加入西安葡萄城。在职业生涯的个十年中，我的角色是企业软件开发人员。我们团队开发的是在日本私立学校管理系统赛道市占率名的LeySer System，这个系统初版发布于1983年，即将迎来4岁生日。我参与了这软件8.0到9.0版本的开发，大多数时间专注于开发框架的迭代与维护，也做过服务端通讯、缓存、权限认证等非业务功能和一部分DevOps自动化工具的开发。我在LeySer开发团队的十年中，亲身经历了产品从局域网到SaaS，再到云加端的部署模式和架构转型。之后的五年中，我先后以项目经理和产品经理的角色在葡萄城的开发部门中工作。2018年之后，公司在中国的业务中心转向低代码，在这个背景下，我加入了低代码产品线，目前主要负责行业研究、生态建设等工作。此外，我以中国信通院低代码无代码推进中心技术专家的身份，正在参与中国首部低代码行业标准的制定，在高校和技术社区讲过一些课程，参与出版了一本技术书籍。

问题2：您在18年转入低代码领域，是什么契机促使您选择低代码这一方向呢？

我转入低代码的原因有两方面。

是看好这项技术的发展前景。我始终认为软件开发工具是一个专业性很强的技术领域，这个领域的进步可以撬动整个软件行业的发展。这是我从企业软件线内部转岗到开发工具线的主要原因。

其次是我所在平台，也就是葡萄城的“基因”。我们公司在1980年开始进入企业软件开发领域，在做自己软件，也就是我刚才提到的LeySer的时候发现其中很多代码是可以复用的。于是我们的前辈在1990年将其中的一些类库抽象出来，做成组件单独销售，从此开启了开发工具产品线，目前类Excel协同办公开发领域中的SpreadJS、.NET平台报表控件ActiveReports是其中的代表。基于服务开发团队的经验和我们对软件开发工具的理解，公司在2012年启动了覆盖软件开发全生命周期的可视化开发解决方案的研发，并将其作为公司未来一段时间的主要发展方向。当初还没有低代码的说法，直到2014年，低代码的概念提出后，我们认为即将发布的新产品与这个概念高度匹配，就定下了的“活字格低代码开发平台”的名称。可以说，葡萄城在6年前就确定了在低代码领域发力的方向。这让我的转型之路更加顺畅一些。

问题3：您认为低代码是什么？低代码可以解决什么问题？

低代码的概念很宽泛，指的是通过图形化等手段降低软件开发编码量的技术，狭义的低代码则是将其应用场景限定为完整的应用开发，即使用更少的代码开发包含有界面、数据模型、业务逻辑、流程和数据服务的完整应用的技术。

回归本质，低代码技术的作用是降低软件开发的技术复杂度。对于很多朋友来说，这个概念可能有些陌生，我来展开讲一下。4多年前，有一本讲软件工程的著作，《人月神话》，可以称得上是我在软件工程领域的个领路人。书中花了很大篇幅在讲软件开发需要解决的复杂度。我们可以将软件开发的复杂度拆解为业务复杂度和技术复杂度两种。前者是由业务需求本身决定的，是本质复杂度，不会因为技术的变更而发生变化；后者则是偶然复杂度，可以随着技术的进步而逐步降低，也有可能因为环境的变化而有所反弹。只要从事软件开发，业务复杂度都是必须要处理的，没有任何技术可以帮到你；而技术复杂度却可以通过引入更高效的开发技术来帮你分担一些技术复杂度问题，中和甚至超越运行环境带来的负面作用，从而提升整体开发效率。

在我从事软件开发行业的十几年里，软件的环境变化速度是要高过软件开发技术的。面向浏览器的B/S架构、网络传输受限的移动互联网、计算能力受限的PDA移动终端，这些技术在提升用户体验的同时，也显著拉高了技术复杂度。直观的感受就是2005年，我入行时，以Visual Basic、Visual Studio为代表的可视化开发技术已经普及，帮我们屏蔽了Windows窗体绘制、消息循环等技术复杂度问题，所见即所得的界面开发效率非常高。但是进入2010的Web开发阶段后，这种“代码自动编辑器”思路的可视化开发工具因为数据传输量大、解析和运行效率低等问题，无法满足应用开发所需。我们又不得不回到像Pascal、C的纯编码的时代，重复写代码、运行起来看效果、再改代码的循环。这就是开发技术在与运行环境的拉锯战中落败的表现。进入2020年代，浏览器的计算性能和网络带宽的紧张程度有所缓解，另一方面，可视化开发技术和与之配套的元数据驱动架构的成熟。两者的共同作用，孵化出了低代码。

从目前的实践上看，低代码技术在业务复杂度高、系统集成要求多、交付周期要求严、预算投入有限，但数据量不大、并发数量不高、界面交互精细化不高的企业软件领域已经展现出很强的竞争力，比如企业生产相关领域的设备维保、库存管理；供应链领域的物流跟踪、经销商采购；客户服务领域的会员积分、在线工单；财务领域的凭证池、预算查询等“重业务场景”。这些场景存在的共同点有以下几个：

1. 价值高， IT投入能带来稳定的收益预期，一把手有足够的压力和动力来推进这些领域的信息化；

2. 差异化，不同行业、不同企业、不同管理文化甚至一个企业所处的不同阶段，这些核心业务都不大一样，很难通过成品软件来实现；

3. 柔性化，不确定性是这个时代的特点，导致了企业业务难以长期稳定，需要不断试错才能找到成长的空间，这就对软件交付的速度提出了更高的要求，“项目还没交付，需求已经变化了”的情况是很难被接受的；

这三点让低代码开发相较于编码开发的优势能得到充分的展现。事实上，在葡萄城和中国软件网联合举办的2022企业级低代码应用大赛中，获得多位来自中国信通院、CSDN、36氪、西安电子科技大学的专家多认可的作品大体上都是符合上述三点。

另一方面，对于一些IT投入比较高的企业，也可以用低代码来解决数据填报、跨系统审批等OA相关的“轻业务场景”，这些场景在成长型企业中通常被IT所忽略。引入低代码，解决“从无到有”，提升信息化的广度也是大功一件。

当然，低代码的局限性也不容易忽视，低代码开发通过组件化封装来提升开发效率，必然会牺牲一定的性能和定制化。虽然这两点在企业软件中并不是核心竞争力，但在其他领域就不一样了。所以，我们不推荐将低代码应用在数据量、并发数和界面交互精细度“卷到天际”的互联网服务的开发中。

问题4：《低代码开发实战》由葡萄城技术团队编写，您也是图书的作者之一。如何组建低代码开发团队？低代码如何与编码开发相结合？以及如何学习低代码？

市面上的低代码产品主要分为两大类，面向业务开发者的低代码和面向专业开发者的低代码。刚才我们提到的低代码中指的是后者，指的是提供给主要做信息化建设的技术人员的低代码平台，如企业内部的IT部门、业务线中负责信息化建设的人员和外部的信息化服务商等。我们公司的活字格产品选择的就是赋能开发者的路线，也被提出低代码概念的Forrester在报告中列为该赛道的典型产品。对于这个方向，我的经验也更丰富一些。

刚才我们讲到了企业软件开发的业务复杂度和技术复杂度。低代码开发团队需要面对的就是这两种复杂度。即便有了低代码，团队依然需要独立解决业务复杂度，通俗的讲就是将业务需求翻译成适合计算机执行的方法。低代码平台厂商则通过平台的内置能力、技术方案和社区资源，承接项目中大部分的技术复杂度。对于复杂一些的项目，依然会有一些技术问题需要开发者借助平台的开放接口和系统集成机制来实现。这种情况决定了成功的低代码开发团队与传统编码开发不同。从我们的经验上看，成功的低代码开发团队大多采用“高低搭配”的模式，初级低代码开发人员占比显著高于低代码开发人员。

1. 低代码开发人员：专注于解决技术复杂度问题，主要职责除了指导和审查初级低代码开发人员的工作外，还需要解决架构设计、数据库设计、性能优化、系统集成等技术复杂度问题。招聘时可参照传统编码开发的后端程序员，重点关注其架构设计、解决方案设计和数据库开发能力。

2. 初级低代码开发人员：负责解决业务复杂度问题，主要职责是在低代码开发人员的指导下，完成页面设计、基础的业务逻辑设计等工作。实际招聘时，可优先考虑非重点大学的计算机相关专业毕业生；或接受来自运维、实施等团队的转岗人员。

低代码与编码开发并不是非此即彼的关系，两者的有机结合才是正解。从我们的经验上看，大型企业级系统中通常可以选择两种低代码与编码开发的解决方案：前后端分离和子系统集成。

1. 前后端分离：参照编码开发中的前后端分离方案，使用低代码平台，可视化开发后端WebAPI，提供给使用编码开发的前端页面（包括网页、桌面端、APP、小程序等）调用；反之亦然。这种模式主要用在为对现有系统进行重构时的过渡方案，如先沿用现有的前端页面，使用低代码开发全新的后端，并基于新的后端延展新的功能模块，后再替换掉之前的前端页面。

2. 子系统集成：将系统中的某些模块采用低代码开发，另外一些模块采用编码开发。两者通过共享数据库或WebAPI实现数据交互。这种做法更为常见，通常用于为现有系统扩充新的功能模块，如为ERP添加供应链自助填报等，或者用于解决一些较为复杂的批量数据处理、私有协议的软硬件集成等场景。值得一提的是，需要将低代码开发的模块与私有或特殊协议的软硬件集成时，可以使用被集成系统的SDK和文档推荐的技术栈开发一个“桥接程序”，将其能力封装为WebAPI后提供给低代码使用。

要想具备以初级低代码开发人员的身份参与到低代码开发团队的能力，低代码学习的重点可以放在低代码平台本身的功能学习上。成熟的低代码平台厂商大多提供了完整的学习路径，包含技能清单、培训资源和认证考试等。在对软件开发有基本了解的前提下，沿用厂商的学习路径通常是优解。以我们的活字格低代码开发平台为例，这一目标对应了学习路径中的“进阶教程”。从经验上看，学习时间大约需要80小时。

对于低代码开发人员来说，除了上述学习外，还需要使用现有的软件工程和架构设计培训资源，掌握相应的技能。这点因为和编码开发没有区别，就不再展开了。

问题4：您怎么看待媒体和大V对低代码的争议？如何看待无代码将从低代码中分离的观点呢？

作为一项2014年提出的面向企业服务的技术概念，低代码的发展速度不能说不快。但8年的时间对于一项企业软件技术来说，依然处在成长和探索的阶段。在探索的过程中，拥有不同基因的厂商选择的方向存在很大的差异性。这导致很长一段时间中，在低代码的名下杂糅了不同的产品和方案。再加之互联网投资的推动，市场端能够听到、看到的低代码就更加百花齐放了。面对一个差异化非常大的市场，不同的人注定会有不同的感受。比如程序员看到由互联网表单工具转型而来、面向业务人员用于解决简单业务场景的产品；或没有IT背景的业务用户看到由软件开发控件转型而来、面向技术人员用于解决复杂业务场景或系统集成的产品。怎么可能不饱受争议呢？

值得高兴的是，低代码市场从去年开始走向分化。在去年年底，我先后接受了Forrester和中国软件行业协会的采访，在沟通中我和两方的专家老师都能明确的感觉到，国内面向业务开发者的低代码产品为了彰显自己的学习门槛更低，正在或即将更名为“无代码”。这种趋势发展下去，必然形成业务人员使用无代码，让一些简单的、临时性的场景，可以不再需要技术人员为其定制开发；另一方面，技术人员则使用低代码产品，专注于搞定更复杂的、需要长期运行和迭代优化的高价值场景。这样，两类用户各取所需，两类产品也能专注研发。我相信低代码技术会更快走向成熟。

问题6：您在低代码行业有近5年经验和行业成就，您对低代码行业从业者是否有一些好的意见和建议？

虽然受到大环境的影响，低代码的投融资活动在降温，但我认为低代码依然处在上升阶段。基于十余年的软件开发经验和低代码行业五年的探索，我有以下几点想法，称不上建议，权做参考。

1. 如果您在低代码平台厂商从事产品研发相关工作，建议保持开放的心态，积极引入新的技术和方案，利用他山之石快速扩充自身的产品能力；

2. 如果您已经是低代码平台的用户，即低代码开发者，请密切关注来自厂商的培训资源。低代码产品的迭代速度很快，紧跟厂商的“佳实践”才能做到事半功倍；

3. 如果您在传统开发团队中从事编码开发，但希望通过转型为全栈开发者，独立承接项目，可以提前学习支持前后端分离的低代码开发平台，按照“一专多能”的方式，用低代码快速补全短板，承接更高价值的项目；

4. 如果您在企业或信息化服务商中负责技术选型和决策，建议提前了解低代码的特点和应用边界，将面向技术人员的低代码平台作为选项之一，找到合适的项目，大幅提升团队的产出效率。即便不将低代码作为，至少可以把低代码作为“后一线”方案，在编码开发的成本和交期无法满足的时候，集中精锐力量，拿起低代码的武器，再战一程；

5. 如果您是关注企业信息化领域的媒体或投资人，建议全面了解低代码领域，理清低代码与无代码的异同后再下结论。否则，低代码的两面性很容易给你带来误解，以至于错过了很好的机遇；