（一）低代码平台-基础知识

一、一个完备的低代码平台应该具备哪些条件？（易用性、效率）

天花板中的低代码平台，要具备哪些条件，易用性、效率高？

1、适用性而言，应同时支持以数据为中心和以流程为中心的开发模式。对于简单的业务，需要提供简洁的开发实现方式，并且需要有非常高效的开发效率，从而可以更好地应对简单业务在数量方面的需求。对于复杂度高的业务，低代码平台需要能提供良好的分步实施策略、自然的衔接方式，同时也要充分考虑并提供兜底策略。业务复杂度过高，低代码平台应该能提供一种方法，允许业务开发人员回退到传统 Pro Code 模式继续开发。并且，这个回退过程应该非常自然 / 内聚、同时尽可能地不影响其他功能的开发。低代码平台能很好地处理好 Pro Code 模式和可视化开发模式之间的关系，且内置编辑器：编码过程智能提示、智能补齐、重构、出错信息及定位等 Native IDE 的功能一个都不能少。

2、适用人员

低代码平台要能支持各种技能水平的人同时使用，多数人的诉求：

• 需要提供数量众多的典型应用范例
• 提供视频形式的教材：多数人不乐意阅读文字，一份文档有数百字时就嫌烦。视频教材最好采用无音频的外挂字幕方式制作，一方面剪辑起来更加方便，一方面外挂字幕方便搜索和定位；
• 出问题或者有疑问时能在第一时间得到帮助：建立客服群平台，开发者可以多与使用者互动，热情耐心地帮助他们解决问题，建立首问责任制。

3、与基础设施和谐相处

一是对运行环境的要求；二是处理好与已有系统，特别是已有数据之间的关系。

对运行时的要求相对简单。有的低代码厂商可以直接提供基于公有云的运行时，这样就更加方便，基本可以做到开箱即用，但要照顾低代码客户在数据和信息安全方面的担忧。除此之外，我们还可以提供虚拟镜像，并支持在多数基于 PaaS 的平台上安装和运行。这个方式往往用于私有云的部署，这是应对客户信息安全担忧的有效方式。

我认为，低代码平台需要同时对这两种部署方式提供支持，特别是需要支持私有化部署方式。这样，无论是内部使用还是对外售卖，都可以做到更加灵活。当然，那些专注于内部使用且用户群明确的低代码平台来说，就不需要过多考虑这个问题了。

低代码平台与已有系统之间的关系，大致分为三种：一是被其他系统集成；二是将其他系统集成到平台中来；三是保持相互独立。虽然，同时支持多种与存量系统融合部署，可以提升低代码平台的适用性，但是我认为没有必要支持所有方式，我们根据自身定位挑选以某种融合方式为主就可以了。更多的情况下，优先发展被集成的能力是一个更好的选择。创造价值的肯定是业务能力，而低代码平台作为一种开发工具，对多数企业来说，是不具备直接创造价值的能力的，因此低代码平台也就很难冲到前面去了。即使对以售卖低代码能力为生的企业来说，低代码的开发能力是直接创造价值的业务，但一般买家购买后，也是将它作为自身的某个子系统，集成进买家自己的其他业务中。

既然低代码平台一般是被集成、作为子系统使用的，那么低代码平台与存量数据之间的关系也就比较明确了。低代码平台需要提供多种能力来获取外部数据，而不是将自身封闭成一个数据孤岛，要求外部将数据导入到平台中去。而外部数据的结构（关系）、存储介质、数据量、获取渠道等都是无法事先确定的。在这样的前提下，低代码平台要用好这些数据，可想而知难度是非常大的、甚至不具有可行性。

但如果是为确切场景下的数据提供定制化的融合方式，难度会低许多，但是代价也很明显，也就是几乎每种场景都需要提供一份定制。因此我们需要通过适当的架构设计，将定制部分与核心部分解耦，最好是能允许业务团队来自行定制。这正是插件系统需要解决的问题。我在第 15 讲里介绍这一点。

如何做到对单点登录的支持、如何考虑对接权限系统，也是被集成时需要着重考虑的能力。同时还需要在权限系统中区分开发态和运行态，开发态下往往要给予开发人员的账号更大的权限，而运行态下则需要做严格管控，避免数据滥用和渗透。开发态与运行态进行物理隔离，是杜绝开发

4、全生命周期

低代码平台的能力必须能够覆盖从需求端到应用下线消亡的全过程。

• D2C（Design to Code）：业界已经有非常成熟、成功的 D2C 实践案例，对于低代码平台来说，从设计稿中识别出关键信息，再实现与低代码平台的对接与编辑，要比纯 D2C 解决方案容易得多；
• UX 设计即开发：有了 D2C 能力后，UX 设计师可以直接提供模板和业务组件。在这个意义下，UX 设计师起到了类似研发人员的作用；
• App 开发能力：这点自不必说，这是低代码的重要且基本作用；
• App 的自动化测试：包含两点，一是要能帮助 App 自动生成测试代码，二是提供一键式测试环境构建、测试执行、测试报告，乃至自动标注出错位置等；
• 应用的版本管理：主要体现为要为应用构建相互独立的开发时环境、系统测试时环境、生产环境等，并能实现应用版本的测试、灰度发布、正式上线、紧急回退等能力；
• 应用生产环境监控：这里包括两点，一是应用运行时基础信息（CPU/ 内存 / 磁盘空间）监控和告警，二是应用埋点数据的植入、采集、分析等。

总体而言：

从适用领域角度看，低代码平台必须能同时支撑以数据为中心和以流程为中心的 App 的开发，这实际上等于需要覆盖大多数企业的开发业务能力。

同时，它还需要能支持不同复杂度业务的开发、兼顾效率。简单的业务开发要简单高效，而对复杂的业务则需要有良好的兜底策略，确保业务需求突破低代码平台能力边界时，可以有相应的应对措施，比如回退到传统 Pro Code 模式继续开发。这一点又给低代码平台提出了需要支持 Low Code 和 Pro Code 混合开发的方式的要求，而且混合的过程需要具有良好的自然过渡和内聚性。

从适用人员角度看，低代码平台需要能同时支持多种能力背景的人同时使用，比如业务专家群体多数无软件技术技能，需要为他们提供更多傻瓜化、可视化的操作。而且，既要照顾到有软件研发技能的群体在他们专业领域里的诉求，为他们提供更接近底层代码，甚至直接提供编码的开发方式，也要照顾这类群体软件技术能力之外的开发诉求，为他们提供可视化的方式，辅助他们完成业务的开发。

而且，低代码平台要有平缓的学习曲线、尽可能地自动化、提供大量的模板和素材，在帮助他们自学的同时，又能帮助他们解决实际问题。

同时，低代码平台也不能只注重开发能力而忽视业务研发生命周期里的其他能力，应该积横向拓展，在需求端和交付端提供能力。

（对于大部分公司来说，低代码能发挥的领域肯定不是核心业务逻辑。能够发挥低代码能力的领域，在我看来，主要有以下几种： 1. 营销活动这种快上快下，用完就扔的业务类型适合 2. 面向B端场景下的代码生成，无动画、UI高要求，但对数据处理逻辑这块有通用性的地方，比较适合）

二、先发展通用能力还是先满足业务需求（通用性和业务定制化？？？）

对业务提交的任何功能需求，都按照最通用情形来考虑。即使对方只要一棵树，仍按照一座森林来考虑，我们不见得就要实际交付一座“森林”，但要为它预留足够的位置；

充分考虑已知场景的共同特征，暂时把它们的个性化特征丢角落里。过多考虑个性化特征只会限制你的想象力，这会牺牲掉许多易用性，但这是权衡之下必要的取舍，这是通用的代价。

任何业务需求，只要能采用已有的功能实现的，决不新增功能；只要保持已有功能通用性不变前提下稍微扩展就能实现的，也决不新增功能；好钢用在刀刃上，资源集中投放到开发新的通用能力上，不分散。

注重提升他们的满意度：倾听他们的痛点，主动热心协助解决问题（编码、出方案等），帮助他们脱困；一般只要他们的自身的需求能按时交付，他们就会很高兴；记住：放低姿态。

再完美的低代码平台也总有能力边界，总有业务团队提一些“奇葩”需求越过这条线。此时通用的功能就可以发挥兜底的作用，让应用能按期交付的同时，也给平台团队喘口气的时间。我们甚至可以根据这个需求的“奇葩”程度决定是否要无视它，即使这个需求下次再来，我还是有办法治它的。这就是兜底策略给的底气！

前期，在资源不充裕的前提下，为了着眼于长期演进，必须坚持优先发展通用化能力的思路，对业务提交的任何功能需求，都按照最通用情形来考虑，同时充分考虑各个场景的共同特征，而暂时忽略他们的个性化特征。坚持采用已有功能来实现各种需求，通过这个方法倒逼已有功能的进一步通用化。

后期，重心就要转移到各个功能的个性化需求上来了，此时要把个性化需求和易用性提升到最高优先级。必要的话，甚至可不惜重新设计各个具体场景的开发流程，以获得更高的自动化开发水平，尽可能高地提升代码的自动生成比例，从而最大化地发挥低代码的开发优势。 

直接一上来就刚刚好按照业务要求的功能来做的话，短期内有明显收益，投入产出比也高，但面对的业务问题稍微变个样，就很难应付。优先发展通用能力是打地基的过程，地基一般都深埋地下，看不到收益，但没有地基地面建筑盖不了2层就要垮

三、基础设施 ：低代码平台研发前需要的基础设施

1、组件集，也称未可视化组件集，对 App 常用功能做组件化封装就是这样一种非常合适的细节管控手段，至于定制能力和适用性，则是通过组件封装时暴露的 API 来说实现的。这里说的组件 API 是指组件的输入属性和输出事件，这是组件外部唯一用于影响组件行为和功能的通道。组件集的能力直接决定了低代码编辑器的开发能力。所以挑选组件集的时候，我们的第一要务是要选一套具有自主可控的组件集，即使它看起来没有那么强大。它最好是你自己或下级团队开发的，这样才具有完全的自主权。至少也要是兄弟单位开发的，而且你要有足够的权限修改它的源码。

参考指标：

• 组件集里至少包含 50 个以上的原子组件和容器类组件，才能基本覆盖完整日常所需；
• 具有良好的视图悬浮（气泡化）功能封装和多层视图叠加管理能力。低代码编辑器往往有密集的配置入口，许多配置项需要就地弹出气泡甚至多级气泡来承载，避免打断当前的开发工作；
• 数据采集类的组件（文本框、数字框、下拉选择等）必须对表单友好，这样才能更容易实现出表单类页面；
• 对常用功能要有统一封装，在 Angular 里称为指令 /Directive，特点是这些功能可以“外挂”到任何普通 dom 节点、组件节点上，实现功能扩展。比如，像任意视图下拉、上传功能、多功能徽标、下拉多级菜单、拖拽功能等功能都值得封装：；
• 一个符号图标库，这个不一定非要自己做，但必须要有。编辑器密集的配置界面上“寸土寸金”，多用图标可以节约许多空间。当然，我们也可以直接使用开源的，font-awesome、material design都提供了不错的基于 svg 的图标库，基本满足日常使用所需。

低代码编辑器的复杂度非常高，特别是在画布界面，有各种各样的编辑器、配置界面、悬浮气泡、对话框等。活动视口（ViewPort）上同时有一两百活动组件都是家常便饭，这对组件的渲染性能和脏检查性能提出了很高的要求。

其次，如果画布上的所见即所得效果不是采用 iframe 实现的，而是在画布上采用一个动态模块直接渲染出来的，那对编辑器的性能要求就直接翻倍了。此时，不仅需要高效渲染编辑器本身，还要在画布上把 App 的运行效果也实时动态渲染出来。另外，有的 App 本身也具有很高的复杂度。这样一来，在画布界面上同时存在两三百个活动组件实例也是可能的。如果原子组件的性能不佳的话，整个画布操作起来就会非常卡，影响开发效率，也影响开发者的心情。

2、皮肤深度定制能力（可选）

低代码编辑器可以很容易地做到一键换肤。在同个色系下实现不同颜色的皮肤难度并不大，而且多数还可以做到热切换皮肤颜色。

换肤能力更进一步的需求是，需要支持跨色系的皮肤。一般来说，至少需要支持有两种基础色系：明亮色系和黑暗色系。同时支持黑白同屏的换肤能力，以及如何做到热切换

在组件集启动研发之前，最好已经有一定基础的 UX 规范了，UX 规范对组件集和业务应用的“面子”有这巨大的影响。但 UX 规范不一定需要完全自己开发，如果资源不允许，完全可以考虑抄抄大厂的作业，阿里的Ant Design和 Google 的Material Design都是不错的选择。腾讯的ISUX和字节的ArcoDesign也是很优秀的，可以通盘接受，也可以基于某个规范做一些定制化。