高低代码平台边界12问

转载本文需注明出处：微信公众号EAWorld，违者必究。

当下的IT市场，低代码大行其道。本质上，低代码是一种抽象理念+配套工具的衍生成果，在IT历史里一直存在。我们更需要关注的是处理好高低开的关系，形成融合方案，方能帮助企业级应用更敏捷的建设。

普元数智研究院首席顾问顾伟、喻吉林通过访谈形式共同围绕目前企业低代码开发建设的市场背景、实施问题、高低开融合等常见问题作了详细解答。

访谈问题概览：

1. 怎么看低代码平台这个市场热点？

2. 低代码平台实施遇到过哪些问题？

3. 高代码平台和低代码平台如何融合？

01.

怎么看低代码平台这个市场热点

Q1：低代码开发平台的目标用户群到底是谁？

喻吉林：我们更多地希望赋予现在的低代码开发平台“行业”或“业务”的含义，让更广泛的人群能够参与到平台使用中。所以，平台不仅仅是一个通用的技术平台，它需要随着业务积累，形成更行业化的模型和元素。

事实上，低代码开发平台的目标，最终一定是在某个行业或领域能够更好地服务于大众，但低代码开发平台并不是仅仅服务于初级人员，用以提升初级人员的业务能力；低代码开发平台更多地是服务于有一定业务知识积累，有一定的业务建模能力的业务专业人员。见过一些工程师，拿着低代码平台开始无序的建设系统，最终的成果依然不及预期，其根本原因是缺少对于业务模型的理解。只有持续运用建模思维提升自己对业务模型的理解，才能够在低代码的使用中得心应手，更加可以提升自身的架构能力。

Q2：以前也有企业做低代码，为何反响一般？

喻吉林：低代码市场很大，国内大小厂商都在做低代码，但获得的收入一般。我认为，低代码不是银弹，本身来说，无论服务于哪个行业，都有其自身的边界。

低代码平台有它的边界和局限性，早期的低代码平台，往往并不能解决所有的问题。建设系统时存在各种不支持的场景，如果总是想着利用低代码自身的功能绕过去，必然给程序带来众多“坏味道”，那自然反响不会好。所以，低代码的建设，更应该关注将典型的业务场景抽象出来，形成标准化的业务模型、业务流程和业务规则，同时提供必要的扩展接口和替换接口，与高代码实现很好的扩展融合，也正是我们不断探索实践中的发展方向。

Q3：国内外对低代码热点的看法上，有什么差异？

顾伟：国外的低代码，通常是通过在线IDE模式来呈现，本质上首先是开发工具，然后才是业务的逐步积累和生态的持续打通。国内的低代码，更多是领域应用的快速配置或生成，通常还会伴随一些BI场景。

另外，国外低代码很注重完整解决方案（比如和原有技术的融合、DevOps等），而国内的大部分低代码会有一个相对封闭的问题，这个是需要逐步解决的，不能最终变成一个新孤岛的引入。

02.

低代码平台实施遇到过哪些问题

Q4：普元低代码平台聚焦的要点有哪些？

顾伟：第一个是适配。“敏捷化”的试错试对很重要。其实我们也做过两个大版本，第一版中，我们追求的是快速地页面设计、流程配置等，在这个过程中，我们发现，模型、UI、标准等在开发中，尤其面向大型的银行，央企时，会有不少问题。比如UI性能不够怎么办？数据模型怎么优化？个性化需求实现不了怎么交付？

所以在第二版中，我们聚焦重点变了，期望在不影响企业现有的技术和管理前提下，能够更好的进行适配。比如，企业已经有流程平台了，那就不要再带一个流程引擎进去了，而是应该和企业现有的流程平台做好适配。

另一个是安全。前段时间“护网行动”中很有感触，安全现在肯定是国家、企业的重点，低代码平台所开发出来的各类资源，能不能具备细粒度API安全、数据安全特性，也是我们的重要关注点。

Q5：到底是数据模型驱动，还是UI模型驱动？

喻吉林：数据模型驱动。现实生活中，用户的交互UI可能更合适，但UI只是我们某些展现形式，核心价值是由背后的模型来决定的。

本质上，由核心数据模型驱动企业业务，需要通过模型的不断抽象和丰富，来解决业务上的困惑，而不只通过UI界面。UI界面是从UI体验工程师出发的，这种方式能够很好地解决用户交互问题，但企业级建模不止有UI模型，UI模型只是企业建模中的一部分。单纯从UI模型出发，并不能解决业务建模的核心问题，脱离企业业务模型谈UI就有些本末倒置的。

Q6：到底是生成代码，还是解析执行？

顾伟：我选择走“生成代码”的模式。需要说明的是，不是说一定要生成出代码，然后走传统高开模式，而是能够生成代码，保障高性能和可维护性。高低开融合，本质上期望的是资源都在一套引擎里运行，切勿一套原生运行、另一套解析执行。如果大家追求应用的性能、个性化、维护性等，建议低开具备生成代码的能力。

Q7：个性化需求一般怎么处理？

顾伟：个性化需求本质上也是一种抽象不够的问题，说白了就是还没有抽象出低开能力来应对。现阶段我们是通过高低开融合来解决这个问题的，随着对场景的逐步积累，相信我们能够更好地应对原来不支持的场景。

Q8：应用和数据的隔离性怎么保障？

顾伟：本质上，高代码和低代码，应该是一套隔离模式。以前高代码，大家的应用和数据基本上是完全隔离的，但为什么到低代码的时候，有些人好像会觉得无所谓了呢？我认为是不对的。

普元低代码，具备和高代码一样的隔离架构设计，高和低共同组成了一个物理上独立的应用，而不是共享在一个平台进程里运行。

03.

高代码平台和低代码平台如何融合

Q9：高代码和低代码平台应该怎么分工？

顾伟：高代码和低代码，最终共同形成了一个完整应用，应用一部分靠高代码实现复杂逻辑和计算，另一部分是则靠低代码实现快速业务。高低开融合，要做到的就是让低开不会成为新的孤岛，所以企业在建设低代码时，一定要结合现有的技术和服务。

或者换一种说法，当下要Java逻辑实现的，肯定是高代码，如果能抽象的自然要低代码。从技术层面，比如写一个流程选参与者的动态计算，那一般是高代码；如果做一层业务化，选择已经做好的规则，比如我的领导，我的下属这种业务上的角色，自然就逐步低代码了，这就是一个合理分工和边界移动的过程。

Q10：高代码和低代码引擎如何能做到一致？

顾伟：高低开融合的核心就是引擎，且必须是一套引擎，包括页面引擎，流程引擎，服务编排引擎，API引擎，访问数据引擎等。如果没有统一引擎，势必会建设成两块东西，比如按会产生冲突，无法融合。在高代码平台基础上补充低代码，需要先花一段时间建设融合引擎的能力，然后定制符合你引擎的低代码平台，不要弄成新的一套平台，最终没法融合管理。

Q11：普元高低代码融合平台优势在哪里？

顾伟：优势之一：我们这版高低代码融合，合理地做了工作切分，这样我们所面向的相对复杂的业务系统支撑力会更大。

优势之二：我们不会特别去改变企业的技术架构，我们更多走的是适配思路，对既有的流程引擎也好，数据引擎也好，通过开放集成，最大化地形成利旧。

Q12：市场会如何发展？客户需求会如何发展？

喻吉林：我展望的低代码平台一定是未来的发展趋势。很多年后，我们不太可能称它为“低代码开发平台”，“Low”这个词就没了。比如，十几年前你买了一部新手机，别人会问你，你买的是“智能”手机还是手机（诺基亚等带键盘的功能手机）？那时对手机的概念就是“有键盘”的手机，如今我们提到手机，想到的肯定是没有键盘的手机。从“智能手机”到“手机”的历程，“智能”这个词就被去掉了，但是“智能“早已深入人心。我相信，未来所有平台都应该朝向更轻量级的代码、更智能化的编码迈进，这是开发平台的标配。

未来的开发平台必将是低代码开发平台，但终将形成一套新的开发平台和新的开发模式，解决应用或业务的问题。每个时期都会有新鲜的血液替代原有的血液，低代码平台是我能看到的一个趋势，新的趋势让我终将看到新一代的开发平台，一定会有一个更开放的模式，帮助更多人参与IT建设中。

低代码平台在业界是否会大卖？我认为，它终将成为我们固有的一个基础设施，能为我们解决很多问题。现在发展也不晚，因为目前没有任何厂商独领风骚，我的判断还没真正定型，都在用各自的方式诠释低代码开发平台，形成未来新的开发模式。

上文在《高低开走向融合，是低成本应用建设的最终解决之道》基础上对高低开融合落地作了进一步阐述，欢迎留言交流。

关于作者：顾伟，普元数智研究院总经理，先后参与中信银行，工商银行，中航信，阿里云等客户定制项目；参与并负责公司多款内部产品研发工作，长期致力于IT项目管理，总体设计，用户体验及咨询工作。擅长OSGI，Eclipse 插件，Web 前端，云计算，CI/CD等领域技术，对新技术有着浓厚的兴趣。

关于作者：喻吉林，普元数智研究院副总经理，参与微服务架构、业务中台架构的设计与实践，拥有多年金融行业IT规划、架构设计与研发经验。