低代码平台的过去、现在与保障思路

随着降本增效如火如荼的推进，不管最终是降本增效，还是降本增笑，过程中还是有一些好的产品形态出来，如低代码平台。接下来就从以下几个方面来阐述。

提到低代码平台，作为接触过.Net开发工具的人，一直有个疑惑：他们两者之间的区别在哪儿呢？低代码这个概念真的是最近才兴起的吗？

后来经过查阅发现，低代码这个概念并不是最近几年才兴起的，概念80年代就已经出现了，只不过是最近几年随着互联网的高速发展及市场的萎靡给带火了起来。

它和.Net的开发工具的区别主要在于以下几点：

「面向群体」

• 低代码更多偏向业务人员及开发人员，主要是搭建模型，快速验证，所支撑的应用不是一个量级

• .Net开发工具更多偏向开发人员去构建企业级的应用

「开发方式」

• 低代码一般是标准化或者场景化，平台内置了很多预设模块、业务逻辑组件及集成服务，可以拿来即用

• .Net开发工具虽然提供了组件拖拽功能，但是更偏向原子性，需要开发人员去补齐代码才可用

「灵活性」

• 低代码更多偏向标准化的通用场景，如果需要高度定制化或者复杂度高的场景，需要借助自定义开发、拓展物料组件的方式去实现

• .Net开发工具具有更多的灵活性去定制场景

解了自身困惑后，我们再来看看，人们对低代码的期待，和实际实践接触过程中，它真的是“银弹”吗？接下来就让我们从 「平台视角」 、 「用户视角」、「需求/场景视角」 三方面来认识它。

首先，作为平台，始终绕不开一个不可能三角：「易于使用（Easy to Use）」、「功能强大（Powerful）」 以及 「系统复杂度低（Low Complexity）」。所以在建设过程中，我们总会遇到各种不适，但是限于目前的资源人力和排期，只能按照优先级逐步完善。

其次，作为用户，我们核心关注的指标就三大类：「低成本」、「高性能」、「高质量」。所以日常在使用过程中，影响这几类的都会是改善重点。

最后，从需求/场景来说，为了保证交付效率，使其在建设过程中就能发挥它的价值，导致它诞生的路径就是为了需求服务的，所以当场景类似时，这部分的价值体现就会很明显，但是当场景差异过大，就需要研发人员赶制。中间这个磨合期及后续工程代码的完备性等会很痛苦。

现在基础特征了解后，假如目前你是作为这个产品的质保人，你会「如何去保障」呢？

❝

其实不管是什么需求要验证，一方面除了初次认识外，更需要去了解它的规则，然后针对规则展开验证，以低代码为例，比如里面元素的增减和显隐、状态的变更等；另一方面更需要了解市面上竞品的能力，及相关群体的特征去开展测试。前者保证它的功能基本可用；后者保证它朝更好的方向去发展。

❞

以下4点是笔者理解质保过程中的重中之重：

1. 「基于场景去测试」，开发这个的目的是为了业务服务，所以优先保证场景搭建、部署及使用有无问题

2. 「基于实现去测试」，因为同一个功能，存在不同的实现方案，且有的依托于公司内部的基建，可能跨多个应用，涉及数据同步等隐形问题，这一类的问题基本都是出了问题，影响面大，所以需要特别关注，因为它的风险偏高

3. 「增量保证的同时，别忘了存量」

4. 「量大时，需要关注部署性能、页面访问性能等相关性能指标」

最后的最后，还是想在多提一句：新产品的出现并不可怕，保障也不可怕，可怕的是，你在面对这个新事物的时候，出现了很多的畏难情绪，这个就特别磨人了。在能力面前，心态是大敌。技术开发的东西如果你经手的项目多了，你就会发现它们其实存在很多想通性的。