日前，Mendix中国团队应邀参加了“智能制造与工业互联网系列公益联播百家讲堂”。在第十期“工业APP”的主题课堂中，Mendix团队数字化专家介绍了低代码开发平台助力工业数字化进行创新、差异化、驱动变革的主题，并通过直播平台与大家进行了相关问题的交流与讨论（课程回顾）。本文针对其中有代表性的问题做了梳理，供大家参考，全部的问题解答请访问Mendix中国开发者论坛。

 

问：SaaS应用本身虽然实现了服务的统一化和标准化，但是本身也降低了灵活性和个性化。如果所有用户的定制化需求SaaS应用都需要满足，那么SaaS云服务商本身又变回了传统的应用定制开发服务商，失去了云平台和云服务。请问老师低代码开发平台是否可以解决这一矛盾?

答：我记得2017年的时候我就跟一位低代码平台从业人事交流过这个问题，那个时候国内低代码的呼声还不高，目前市面上大部分低代码的产品当时都还没有切换到这个赛道来。当时我们讨论说，硅谷有个声音叫“SaaS已死”，听起来有些耸人听闻，但也确实反映了一些问题，尤其是SaaS在中国市场面临的一些问题。包括您提到的，当前SaaS的所谓“统一化和标准化”并不能完全契合复杂、差异化的企业级场景，又欠缺灵活性和个性化，这是SaaS产品天然的局限性；另外，很多企业级软件做SaaS是没有经过精心计划和准备的，赶鸭子上架把原来的本地部署产品套了个SaaS的壳推向市场，既没有达到云原生的优势又丧失了本地部署版本的可扩展性，长远来看这是得不偿失的。因此，无论从客户还是实施商的角度看，纯SaaS落地起来很困难。而低代码开发平台的出现，恰好缓解了这个“尴尬”。从几个角度来看：

1. 方案角度，外部灵活扩展取代固有核心更改是大势所趋：现在的企业级软件厂商自己也开始从产品内部进行统一化和标准化，不推荐客户在产品里面做过多的定制开发、增强甚至修改，转而鼓励更多的使用标准服务与统一接口（当然这背后也有整体产品线战略的考量）；但是软件厂商相关的拓展平台及工具支撑还没有到位，或者平台太重，对客户来说投资回报率不高。因此，低代码的平台优势其实是客户和实施商“内心深处的呼唤”；
2. 投资回报角度，一锤子买卖终究不长远，投入产出良性循环才可持续。对成规模的企业来讲，每年1-2千万的定制开发项目投资里大部分的产出内容是“不可再生资源”，比如占比很重的UI；而且随着企业战略、市场、政策等内外部环境变化带来的需求越来越多，越来越频繁，这样的长交付周期“摒”起来会越来越吃力。因此，企业需要为开发平台做3-5年甚至更长远的规划，需要一个能与需求节奏相匹配的灵活、低成本、可复用的开发机制。对服务商来讲，也是如此，靠疯狂砸人卖项目、卖服务的时代可能已经渐行渐远，“margin”的压力一年比一年大，人才流失或者说轮换越来越频繁。本来前一个项目的积累可以带到下一个项目的这种模式优势，也因此变得“靠不住”。因此，把成果和价值产品化，模块化，把交付模式敏捷化会成为大部分软件服务商的“持久生存之道”。
3. 质量角度，“十四五”把“高质量，高品质，高效能”放在核心位置，它不单是空的口号，是大到国家治理，小到企业日常工作、项目开发的真实关切。其实这个问题本身跟低代码开发平台无关也有关。无关，是因为这本质是软件工程问题，是软件设计、开发本身就应该有质量要求：优化的架构设计，可扩展性、可维护性、性能、安全的考量，包括每个开发者都要遵循的开发规范等等。无论你用什么开发语言，这些问题都要去考虑。比方说select *的问题，嵌套循环里读写数据库的问题，大表胡乱join的问题，想用数据就去数据库读从不考虑读写优化的问题。。。等等， 这些你平时开发就不管，那你换什么工具、平台都一样，从来都没有什么“救世主”；有关，是因为好的工具和平台可以帮助规避一些问题，帮助带来思维的变革和“最佳实践”。标准化其实没什么不好，举个例子，很多情况下你不用自己写接口了，平台帮你搭架子，你只要往里塞参数就好，也不会有数据类型错误的担忧，或者也有些语言里传值还是传址带来的性能担忧了；另外，标准化一定程度避免了多元化开发团队里代码习惯参差不齐造成维护困难的问题；再者，微流(Mendix Micro Flow)的设计是程序逻辑的体现，是的片段代码的可读性和可维护性大大提升。质量的问题，要展开讨论可以有很多方面，总结下来就是遵循科学规律的前提下去理解和使用一个现代化的工具，才能有效提升生产力。这是一个普世价值观。

花了这么多篇幅回答这个问题，是因为问题本身很有意义，也很重要，从我们的芯片行业到软件行业，为什么发展这么多年现在看来差距还很大，因为有时候我们就是多了想“弯道超车”的浮躁，缺了些静下心来的理解和思考。观念理清楚了，事情做起来才能顺理成章，所谓“言不顺则事不成”。

 

问：从您的角度看，什么是低代码/无代码开发？业界对于低代码/无代码开发是否存在其他不同的理解？

答：无代码其实有两个境界，或者两个阶段。一个是初级阶段，即基本没有代码开发经验的人通过托拉拽的方式就能开发一个APP出来，比如可以参照Mendix官网的demo，通过无代码开发平台Mendix Studio开发一个个人银行移动终端的App，很多“低代码”的产品的表单化开发也是这种，不需要编码，但开发的场景相对简单；另一个就是集大成的阶段，当企业通过低代码平台构建了自己完整地可复用组件库，各种面向业务的功能都完美地封装成“积木”，业务人员可以通过拖拽的方式开发自己的APP，最容易实现的可能就是各种Dashboard；在这两者之间的阶段，就是低代码了，平台提供丰富的组件库，强大的连接能力，开发者也需要编写少量的代码来开发一个较复杂的企业级应用。比如一个零售场景，前端有丰富的可复用模板快速搭台，后台连接PLM和ERP交换数据。

谈到业界的理解，我认为不同的低代码提供商是有自己的市场定位的。有些是更关注无代码市场的，一方面这里的技术门槛相对较低，另一方面是自身在特定领域有一定的积累，将原有的服务特定的功能做个封装就可以迅速进入低代码的赛道。同时这类产品也是服务特定场景客户的，不具备通用性；

另外有些从业者也是奔着可支持复杂企业级场景的开发能力去努力的，这里面核心的能力就是通用的“低代码化”的能力，这个是体现核心研发能力的。Mendix 2005年创立到现在16年的积累，不光光体现在丰富的可复用组件和企业级的连接器，在整个软件开发生命周期的每个阶段，都是有强大的技术支撑，所以可以做到 “大道至简”，将复杂的企业级开发场景以简单的形式开发出来。

 

问： 有开发者认为低代码平台会对开发团队的效率与创新产生负面影响，中小企业的业务流程需要根据平台流程做妥协，老师您对此怎么看?

答：效率与创新恰恰是低代码开发平台带来的优势，如果企业觉得引入低代码开发平台反而在效率与创新上遇到了阻碍，不妨参考以上两个问题的答案，看看是否能找到新的思路。如果仍然有疑问，我们可以举具体的例子探讨一下。

 

问：目前在用户和软件应用之间隔着程序员，以后这一层要逐步消融，之后是用户直接面对场景编程了，那程序员的工作岂不是危险了？

答：我很理解这样的心理， IT开发人员有这样的担忧也很正常。新生产力出现的时候总会有这样的担忧，就如同自动化、大批量生产出现的时候装配工人担心事业，人工智能机器人出现的时候大家担心将来人类会灭亡一样。深层次考虑，这其实是企业IT治理模式的问题。问题的出发点其实是对现有IT治理模式面对低代码开发平台这样创新性产品应当如何调整的、负责任的思考。

IT治理是个很大的话题，可以找时间开个专题讨论，这里只分享几点看法：

1. 总体来讲，企业数字化转型基本途径都会是往“软件驱动型企业”的方向走，最终是软件驱动业务不断革新，可持续地创造价值；软件驱动型企业这个大目标，不单单是CIO的责任，需要整个企业层面的努力，但IT终究还是中流砥柱，要负起相应的Responsibility；因此，IT不仅不会被取代，反倒是需要有核心的担当；
2. 释放业务及其他有热情的角色的创新能动性，其实最终是在帮IT减负：从业务交付的角度看，业务参与了整个功能的设计、开发，就有了使命感和责任感，最终上线的时候推广啊、培训啊这些环节效率会大大提升，交付更准确，沟通更顺畅，推广更便利等等。。没有什么比组成战略同盟更好的协作方式了。从软件开发的角度来看，就像团队带新人，新人刚上手的时候你给他分配一些力所能及的事情，教会他正确的做事方式，他就会慢慢成为你的帮手，大大提升你工作的效率； 趁手的工具，优秀的平台，只会让优秀的团队更优秀，不会成为负担。
3. 上述分析也有提到，无代码、低代码、全代码是有各自适用的场景、适合的角色的，大家协作完成任务。下图比较好的概括了这一情况，总的来说：

• 复杂性高、开发难度大、交付周期长企业应用，依然需要专业的IT人员完成，这部分需求可能相对数量不大，但属于系统化工程，对软件能力要求高。比如核心流程的扩展，多数据源、多系统、多价值链的打通等等；
• 复杂性低、开发工作相对容易、交付周期短的灵活应用，可以交由经过培训的业务及其他人员完成开发工作，但软件质量管控、最终发布部署等工作，可以由IT统一完成。（有些企业业务的软件能力强、自治体系完备的另作讨论，需结合自己现有的IT治理策略）

问：前端团队只有互联网大厂可以配置，维护vue/react/flutter是没问题的，大部分厂是没有前端的，最多懂一点jquery，对于这种现象老师您怎么看？

答：Mendix实际上在前端做了很多的封装，我们提供大量的模板和控件供选择使用，实际上是不需要太多的前端技能就可以开发出丰富的应用的。像下图这些界面，都是通过标准组件开发出来的。

 

问：您认为低代码的最大优势是什么？

答：从企业级使用场景的角度看，最终衡量的点还是在业务价值上，能不能够更高效能地实现业务价值；从企业整体战略层面看，他是不是可以帮助企业形成一个持续输出业务价值、创新能力的平台，帮助企业落地数字化战略，甚至是给企业数字化战略提供一些思路。至于其他的，10倍速开发，70%的成本节省，多种体验的应用，包括业务和IT在内的高效的协同等等，只是这个过程中的一些表现而已。

 

问：如果低代码开发平台的组件存在质量或安全漏洞问题，开发出的应用程序的稳定性和安全性就会受到影响，而且是无法控制的。低代码开发工具交给普通开发人员使用，意味着企业冒着一定的风险。 Mendix是怎么保障安全的？

答：产品测，如果企业正在使用的其他企业级软件产品一样，Mendix的产品是有严格的安全标准的（可参考Security for Cloud and On-Premises Deployment或Mendix官网安全与合规内容）；如果是企业自己开发的组件，需要依照企业自己的软件质量与安全标准去开发和发布，这一点，无论用什么样的开发语言和平台都需要重点关注。同时，低代码降低了开发的门槛，让没有开发经验的人也可以参与开发，并非指开发、测试、发布的全过程都由开发者完成，整个过程还是需要符合企业软件质量管理和IT管理规范的，参照上述IT治理的问题讨论。不应造成“低代码让大家随便开发并发布到生产环境，不考虑质量及安全问题”这样的误读。

 

问：各个管理软件系统之间数据不共通，如信息孤岛之类的问题，低代码开发可以解决这个问题吗？

答：为企业级开发服务的低代码开发平台应该具备串联数据、集成企业及软件、打通企业端到端价值链的能力。Mendix低代码开发平台所具备的以下集成能力正是服务于这样的诉求的：

• 为SAP、西门子数字工业软件（包括Teamcenter）、IBM和Salesforce等系统预装连接器
• 无需代码即可连接和创建REST、SOAP、XML和OData
• 使用与所有典型数据库系统兼容的简单操作来构建任何数据库，可连接关系型，分布式，图形数据库
• 集成核心应用系统或服务，AI，IOT等
• 智能连接物联网、机器学习、流媒体等
• 可使用/调用已有的成果库（如JAVA，JS开发的成果）

 

问：低代码开发平台封装的组件是否会限制了专业程序员的使用和发挥？

答：这是个辩证的问题，从IT管理方法论的角度来讲，自由度越大，管理成本越高；自由度越小，管理成本越低。我们从程序员的“专业”程度来看，第一阶段，当他不专业的时候，是来一个功能做一个功能，每个需求做一版程序；第二阶段，当他稍微有些经验的时候，会把原来的代码存好，下一次类似需求可复用的时候就复制粘贴过来然后修改使用；再进阶到第三阶段，程序员脑子里会有清晰的架构，可复用的功能也尽量的模块化，形成自己可复用函数/模块库，这其实和Mendix的组件库理念上是一致的，本质上是一种开发过程的优化。

对大部分处在第一、第二阶段的程序员来说，封装的、标准化的组件其实是好处大于局限性的。首先，不用自己考虑可复用性，直接拿来主义；其次，不必考虑接口/函数调用的语法问题、接口规范、编程习惯问题等等，整体程序质量是有提升的；再者，丰富的模板与连接器帮助他们批量化的高效率地完成任务。总之既提升了交付能力，又获得了开发过程的愉悦感。

对于第三阶段的“专业”开发者来说，首先Mendix低代码开发平台提供的专业代码开发能力，可以使他们继续在自己的VSCode, Eclipse环境中开发，然后把代码嵌入Mendix；同时，Mendix帮助他们快速搭建前端，通过微流快速连接程序逻辑，使专业代码开发和低代码能力相结合，事半功倍。总之，对于专业开发者来说，Mendix的多种能力总有一些是你“用的上的”，而且是提高效率的。最直观的例子就是SAP Fiori，传统SAP扩展项目开发中30-50%的人天花在Fiori上，如果使用Mendix（内嵌Fiori风格的模板与控件），这部分效率基本是10以上的提升（这个数字是北美SAP用户协会调查的结果）。

 

问：请问Mendix是否可以类似IOS和Android，对全球的工程师开放，开发更多的工业app或者类似小程序，以赋能更多的公司和业务？

答：Mendix目前全球注册开发者已经接近19万，进入中国以后更是增长迅猛，这些开发者基于Mendix开发的应用、组件，或撰写的Mendix技术文章等分部在各种资源渠道，Mendix App Store, Github，Slack， CSDN，Mendix中国开发者论坛等。这些资源使Mendix开发生态圈越来越大，也给企业级应用开发提供了很好的赋能手段。

针对开源的问题，这里也可以稍作探讨。国内有不少声音在讨论：包括Mendix在内的低代码开发平台是否可以做到完全开源？这个问题需要理性看待。首先，这是商业规则的问题，目前行业头部企业（包括Mendix, Outsystems, Salesforce,微软），在低代码平台的技术积累都超过了十年，每家都有核心技术，打破规则去开源不光是勇气问题，可能还涉及各种法律合规问题；其次，国内低代码平台大多起步于2018年前后，技术积累不多，且有些还是基于开源框架做的，其真正的低代码能力、平台的通用支持能力要打个问号，这样的开源与不开源，其实差别不大；再次，现阶段平台开源对于企业级应用开发帮助不大。Mendix低代码平台05年以来已经服务了全球4000+的企业，他们基于Mendix做企业应用，或者自定义组件、控件来满足应用开发需求，这使得Mendix的组件资源也不断丰富，我国企业对低代码的了解才刚开始，高效且实际的选择是把重心放在充分利用已经由别人积累好的资源来构建企业应用层面，平台本身的开源共建就现阶段来讲没有太多的现实意义。

 

问：国外数字厂商对国内中小企业数字化转型升级可有优于国内数字化服务商服务增值点？

答：数字化转型也提了很多年了，其实总结下来就是：没有捷径可走，不管是软件厂商、服务商还是企业，定好计划、踏实执行最重要。如果说要借鉴的话，我认为国外的经验有三点值得引起我们的思考：

1. 产品基础扎实

比较市面上的工业自动化、数字化软件、企业管理软件包括低代码开发平台，我们不难发现，国外的软件无论是对行业及业务的理解深度，对业务逻辑的尊重，对软件工程的尊重等等很多方面，都是值得我们借鉴的。这些产品从产生到迭代、升级，其出发点都是为了企业业务稳定运行和长远发展保驾护航，某种程度上不刻意迎合企业走捷径的需求。

当然随着我国经济发展的多样化，尤其是在新零售、消费品、互联网、人工智能等领域领先全球，国外的软件在这些领域显得灵活度不够，表现出很多“没见过世面”的短板。但总体来讲，他们做软件还是认真的，产品测还是比较扎实的。

2. 规划思路清楚

数字化转型总体需要按部就班，方法上无外乎以下几步：

• 着眼点要大，起步点要小，积跬步然后至千里
• 敏捷：勇敢POC，快速迭代、小步快跑
• 以长远价值为驱动，以落地路线图为指导，按小、中、大切分执行
• 与时俱进，用行业先进技术与解决方案武装自己
• 建立战略合作生态及高层治理模式

      不管是对服务商还是企业，着眼长远价值，不追求短期利益，客观面对，认真规划很重要。就像是做企业级软件，你的软件是基于某几个客户的项目、需求攒出来的，还是按照行业特性、认真梳理业务场景、比客户看得更远去设计和开发软件，这区别很大。

3. 企业执行踏实

“中国速度”之所以另世界刮目相看，源于清晰规划和高效执行。企业数字化战略的执行也要一样，不能换一届领导路就要重新铺，规划清楚之后就要坚决执行，这就体现了“高层治理模式”的重要性。

另外一个非常有用的“增值点”就是POC，POC真的是个非常好的模式。从产品研发角度来讲叫MVP（最小可用产品），就是要通过小范围的试验，快速试错，迅速找到新技术、新产品与企业需求的最优配合节奏，然后由小及大，由点及面，以求稳步快跑。