关于CodeWave低代码低门槛诉求的调研与思考

我们所开发的codewave开发平台的定位是低门槛、高上限，让更多的人甚至完全没有软件开发经验的人能够短时间培训后掌握软件开发技能，开发和交付专业的企业级软件。而实现低门槛最基础的原理是：减少开发所需要掌握的概念数量。传统的开发模式下对开发者一大挑战是软件开发知识体系的开放性，实现同样的功能有大量的技术路径可以选择，需要根据实际场景进行选择取舍， 而一旦将需要应对的场景缩小，例如缩小到企业信息管理类的web应用场景，那么就可以将技术栈标准化，提供适合场景的框架，简化编程语言来将所需掌握的概念数量极大减少，从而开发者之需要在一个封闭的知识体系内提升熟练度就能精进软件开发的能力。而高上限的实现则与抽象粒度密切相关，抽象粒度太粗就会损失灵活性，例如一些0代码平台将软件抽象为表单、流程表单、报表，当所需的交互形式和业务逻辑超出这些预置的场景之外就无法完成。因此codewave这样追求高上限的开发平台选择的抽象粒度是数据模型、逻辑、视图。 但低门槛与高上限如何平衡和统一就是开发平台产品最大的挑战了，高上限更细的抽象粒度显然就会带来更多的概念数量， 用更细粒度的能力搭建应用显然复杂性也会高于粗粒度的能力，解决这一问题的方法主要还是在于识别用户的场景，对能识别出的最主要的场景提供相应的能力封装，减少概念数。低代码应用开发入口-网易数帆

codewave推向市场后我们也是如预期的收到了一些关于上手门槛较高的反馈，其中，来自专业开发人员的反馈主要是灵活性虽然比较强，但在一些简单场景下需要掌握的概念，完成功能需要的操作步骤还是太多了，希望常见的简单场景能够更高效的完成。 而对于没有专业背景的业务人员或新手，直接的问题是一些概念理解不了，例如变量、结构体、变量绑定、逻辑、布局容器等概念都较难理解，这类用户能接受的更多是对页面中的组件进行一些可视化的配置，以及设置一些验证规则等表达式逻辑。对于这样的情况我们进一步对用户进行了更深入的调研，识别了一些更具体的场景，并挖掘出了产品的在降低门槛方向上的演进思路，下面展开介绍。

首先，我们发现用户在开发过程中大量时间用在了UI布局上，并且无论是客户侧的开发者还是我方培训的低代码教练，都反馈了UI布局比较困难，花费大量时间的情况。究其原因codewave设计初期在UI布局方面更多考虑了灵活性，直接搬了前端开发的习惯到低代码，更多做的只是提供可视化拖拽、配置的体验， 实际还是要对线性布局、删格布局盒模型等概念有所了解或进行学习，前端开发的习惯更依赖于用户对于目标效果的分解与计算，难度明显较高。而codewave面向的人群几乎原本都没有前端开发经验，前端开发的习惯与用户的心智模型不符，简单来说就是不符合直觉。在codewave的用户中大部分新手原始的UI设计概念都来自于PPT这样的工具，自由的拖放、对齐、拖拽调整尺寸他们主要的习惯。另外有一部分用户来自于产品经理、交互设计师等群体，他们的习惯是Figma，MasterGo，Axure等设计/原型工具。 因此要降低UI布局的开发门槛我们可以从满足用户的心智模型，让开发过程符合用户的直觉来开展。为此我们启动了自由布局容器的项目，目标是让大部分用户都只需要通过自由布局容器就能够完成UI界面的开发，功能上既提供了自由拖放的体验，也提供了类似Figma可以声明布局约束规则的能力，让两类群体都能够轻松上手。而从初步的用研测试情况看对于一些交互视觉个性化程度较高的页面效率有2-10倍不等的提升，易用性的评分也提升了40%左右，也印证了我们选择的方向确实匹配了用户的需求。另外自由布局能力的引入还带来了一些全新的可能性。我们接触过一些客户项目交付过程中有明确的产品原型设计阶段，这些客户指出产品经理或交互设计师提供一个设计稿，然后再靠研发还原设计稿是一个很大的成本，并且十分影响对客户需求响应的速度，他们期望通过codewave能够让产品经理直接通过UI设计器完成原型定义，然后再由研发为原型补充上业务逻辑，从而免去技术还原原型稿的工作。 我们认为这是一个很好的方向，能够让更多的业务人员参与到软件开发过程中来，并大幅降低软件开发协作成本。而要实现这种协作模式则需要让UI能够真正与逻辑解耦，并支持预览，这是codewave后续演进可以发展的一个非常有竞争力的能力。

其次，我们看到一些典型的实现简单功能，但需要了解的概念太多，操作也过于复杂的问题，这类问题我们归结为开发框架问题。例如一个例子是在技术支持群内我不止一次看到用户问如何根据鼠标事件来改变一个组件的背景颜色等效果，其具体操作步骤如下：

• 创建一个bgColor变量
• 在组件的属性栏中将组件的背景色与变量绑定
• 在组件的事件栏选择需要响应的事件类型
• 创建事件响应函数在事件响应函数中将变量设置为对应的颜色值

可以看到对于如此简单的一个需求，操作步骤是比较复杂的，并且其中有两个开发者没必要感知的概念变量和绑定。而当前之所以需要理解这些概念是由于面向一些组件嵌套结构比较复杂，组件间有联动，动态性要求比较高的场景时希望根据数据和业务逻辑的要求对组件属性进行动态的控制，从而能够做到只要控制对应的数据模型就能改变组件的状态。然而在很多基础的场景下并不需要这样的动态特性，用户只是想对当前事件关联的组件或者当前被渲染的组件的状态进行控制。从而将步骤简化为

• 在组件的事件栏选择需要响应的事件类型
• 为事件添加逻辑，对事件相关的当前组件的是属性执行赋值操作

这样就免去了开发者需要理解变量和绑定概念的负担，操作步骤也减少了一半。而要做到这点需要我们在开发框架层面提供与组件绑定的属性值，以及为属性值赋值的能力。

与开发框架相关的还有一些过度暴露了底层概念缺乏封装的例子，例如：步骤条是较为常见的简单前端组件，但最近review组件的设计时发现一个设计问题。步骤条组件的bad smell可以从下面这张截图中发现

这里有个显著的问题：当要实现在第一步或最后一步时不显示上一步按钮，依赖了组件的状态值step（代表当前进行到第几个步骤）这一实现细节。合适的做法是提供hasPreviousStep()，hasNextStep()等接口，从而屏蔽存在step状态的细节。

从开发框架相关问题我们可以看到在已识别出主流使用场景的情况下，我们应该通过开发框架帮助用户封装概念，以避免用户需要理解更底层的概念细节，对于这类问题应当在平台中举一反三，制定设计原则，从而使平台随着我们对用户使用场景的理解更加深刻，而变得更加简单易用。

最后，我们在市场上所感受到的一个重要的需求是怎样让业务人员也能使用codewave开发平台，我们观察到由于业务人员不是全职开发角色，很难让他们接受一定强度的培训考核来掌握低代码的编程概念。并且，在市场上很多业务人员已接触过0代码的概念，对于0代码提供的配置加规则编写这样的开发体验相对更容易接受，而对变量、逻辑、数据模型等概念很难理解。而要满足业务人员的低门槛要求，我们需要先对他们能够接受的0代码的本质进行剖析。为什么0代码几乎都只提供表单、流程表单、报表这样的粗粒度的抽象，为什么0代码平台开发简单场景所需要的概念和开发步骤远小于低代码？ 对此我们可以给出一个关键词“意图”，通过识别意图，我们可以了解到用户希望解决的问题的范围，从而大幅缩小问题解决策略的搜索空间。典型的例如在程序综合中，设计合理的specification能够有助于限制搜索空间。对于AI我们给出更加精准的prompt和上下文能够使解决问题的成功率提升。而对于0代码这样的场景，当用户表达出“我要制作一张表单”这样的意图，那么就可以大幅裁剪接下来用户可能的编辑场景的范围，例如表单布局的自由度可以裁减至单栏到3拦的固定布局，每个表单内控件一般都会配一个文字标签，表单控件可以根据用户权限配置是否可见、可编辑等状态。可以裁剪掉表单内部与列表协同，表单数据与外部数据协同进行复杂逻辑计算等几乎无穷无尽的个性化场景。而零代码通常只有表单、流程表单、报表几个场景的原因就在于这几个开发意图对于简单应用场景最为常见，并且这些意图之下的主要场景最容易识别。 而一旦这种基于意图裁剪搜索空间的手段用于更广泛的场景，代价就会变得高昂，例如如果抽象出一个生产排班组件，如果各行业的排班需求不同，需要的交互形式表现形式不同，就会无法根据生产排班这个意图来识别主要的场景，从而无法实现0代码的效果。理解了0代码的原理，我们可以采用的策略也就明确了：我们可以为用户提供一种“引擎式”的组件，用户将这个组件拖到画布上就表达了对应的意图，然后再该组件内我们可以基于低代码的接口和DSL为用户封装提供0码体验的封装，从而使用户能在低代码平台中获得0码的能力，更进一步的是由于引擎式组件实际生成的都是低代码的DSL，也使得我们可以在有更加个性化需求时支持用户脱离0码编辑体验进入低代码编辑，以实现个性化需求。当前我们已按照此技术思路开展了“表单引擎”的概念验证，并完成了产品和技术验证，接下来可沿着这条技术路线进行演进。

在对0码分析的过程中，我们还进一步关注到了流程这个更加复杂的场景，当前开发者会发现在codewave中开发审批流程会比0码复杂不少，这里我们同样发现了基于意图的表达降低开发门槛的问题。我们发现0码之所以流程开发更简单，其根本在于识别了开发“审批流”这个意图，所谓审批流主流的形式是基于一张与流程的上下文绑定的“流程表单”在不同的审批角色间流转，其复杂性主要在于审批角色、条件、审批节点流转的灵活性，简单之处是只需基于一张表单流转，不需要与业务领域模型，协作逻辑，外部服务之间产生很复杂的关联。而国内企业大部分的场景也均为审批流，真正需要与业务数据和其他业务系统协同的“业务流”场景更多的是以逻辑来进行承载，很少依赖流程引擎。而codewave初期定位在审批流场景下以集成第三方为主，在业务流场景提供一定的灵活性，能够覆盖审批流场景，这样的策略使得没有第三方流程引擎的情况下开发审批流变得较为复杂。针对此问题，我们计划沿着“表单引擎”的技术路线，继续实现“流程表单“以提供和0码体验类似的审批流开发场景，此时由于流程只需绑定一张表单，就免去了用户需要接触大量流程参数的概念。

通过对用户实际使用场景的剖析使，我们在”降低开发门槛“这一目标上已能够逐渐的收敛所需要的产品、技术能力，制定相应的目标。 这个过程中最大的感受是，只有始终保持以客户为中心的产品迭代演进的理念，我们才能够在低代码开发平台这样高度复杂的产品的发展路径上找到高价值的发力点，集中力量提升产品竞争力，打造更符合市场需求的产品， 另一方面我们也要抓住问题的本质才能避免头痛医头，脚痛医脚的救火工作状态。希望接下来通过这些能力的逐步落地，能够真正能在低门槛、高上限这一定位上做到业界最为领先的水平。

CodeWave智能开发平台注册地址：低代码应用开发入口-网易数帆