低代码——不应该只是玩具

低代码——不应该只是玩具

你是否听过低代码？你是否知道最近几年低代码非常火，国内外产品非常多？你是否试用过一些低代码产品，期望很高却失望而止？我也一样！我试用过不下10种低代码产品，结论是：国内的低代码产品，当前只是玩具！

说他们是玩具，并不是说他们没有价值！玩具也有玩具的价值。他们确实能解决一些特定场景问题，比如，做一个产品问题收集表单、或者做一个办公用品申请流程等。

但是低代码——不应该只是玩具

低代码不应该只是在蛋糕上加颗樱桃，还需要提供生产蛋糕的能力。低代码需要解决企业的业务问题，提供生产加工的整套能力，才能真正为企业的数字化转型赋能，空有樱桃，而无蛋糕是会饿死的。收集表单的场景太零碎，并且从业务上讲，收集来的数据需要进一步处理，这时该怎么办？如果企业做了一堆收集表单类的所谓低代码应用，一个应用就是一个烟囱，这无疑会加剧企业应用烟囱的现象，与企业数字化转型背道而驰。办公流程类的场景，最合适的自定义方式，是在办公软件的平台上去做，而不是使用单独的低代码产品。低代码产品出现的真正价值是提高研发效率，降低研发的准入门槛，解决真正的业务问题。低代码火的一个关键市场驱动因素，是企业数字化转型需要大量优质开发人员，而市场的供给方无法满足。那么，解决这个问题有3种思路：

1. 提高研发人员的效率2. 降低研发人员的门槛3. 让业务人员自己开发

第3条思路就是现在的“表单+流程”类的低代码产品的思路，我认为第3条思路最不可取，业务人员可以做一些最简单的自定义，一旦需要进一步自定义，“表单+流程”类的低代码产品捉襟见肘，业务人员也没有能力做进一步的自定义。

什么才是业务？

业务是：业务对象+业务操作（名词+动词），是主谓结构的短语，比如用户管理、订单管理、商品上架、商品购买等。从认知心理学上，人类天生就区分名词和动词。所以，你会发现，所有的IT系统全部都是业务对象+业务操作，这符合人类写在DNA中的直觉。而表单+流程的低代码产品做不了这样的业务，下图对比一下。

真正能解决业务问题的低代码产品，应该具备如下特点：

可视化便捷操作（这是低代码的标配）能支持业务对象+业务操作（这是能处理业务的标配）面向开发人员，提高开发效率必要时能与代码混用

上面已经提到，低代码平台必须提供足够的灵活性，最高的灵活性是能方便地切换成代码。Salesforce也提供了很高的灵活性，用户可以使用代码自定义，但是，用户需要学习Salesfoce自创的编程语言Apex。最优的方式是，用户可以使用自己熟悉的编程语言、编程框架进行自定义。

行云创新对低代码的探索

而行云创新正是秉持上述的理念来做低代码产品。下图为一个0基础的测试人员，花了两天，使用行云创新低代码产品Methodot做出来了一个漂亮的CRM。

使用行云创新产品Methodot （​​https://methodot.com/?hmsr=C23&hmpl=A16​​）能够将低代码与代码混用，如下是一个电商应用，我们将它设计成一张可以直接部署成应用的架构图。该架构图中，front-end是拖拉拽实现的前端，goods、user、order、pay是使用代码实现的后端，它们提供API。前端设计完页面，绑定后端提供的API即可。

在我们接下来的产品规划中，用户完全能够不写代码实现复杂业务（想知道如何做到？可扫码下方二维码与我们探讨）。而更远的未来，我们也许可以将上面的这张架构图变成钢铁侠的实验室，这一天我相信能够到来。

扫码备注“低代码”，加入技术交流群，我们一起讨论~

欢迎给我们提意见，我们一起探讨，一起创造开发者的未来。

​

​

​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。