过去两年先后在不同公司做过两套低代码平台，分别是 中后台低代码 和 H5页面低代码。加上一些在 BI和工作流 等B端软件的经验。在这里总结一下关于低代码平台设计和工具软件设计的一些思考。主要分为两篇文章，第一篇主要说下我对低代码平台的思考和观点，下篇文章会聊聊到实现细节。
低代码开发平台是无需编码（零代码）或通过少量代码就可以快速生成应用程序的开发平台。通过可视化进行应用程序开发的方法，使具有不同经验水平的开发人员可以通过图形化的用户界面，使用拖拽组件和模型驱动的逻辑来创建网页和移动应用程序。 —— 百度百科 这是百度百科对低代码平台的解释。在我看来，计算机科学的本质就是一层层的封装，从机器码到汇编语言，从C语言到Java。底层的复杂度和不确定性被一层层封装。而低代码就是这样的又一层封装，有足够潜力成为新一层软件研发基础设施的平台。
低代码从来不是一个新概念，低代码的模式就是为了不使用代码而搭建软件的平台。如果我们广义的来看，Word、Excel也可以算作是一种低代码。了解计算机图形学都应该知道，我们让计算机显示出规整的图形表格是多么不容易的一件事。Word 和 Excel 中的公式和宏的概念就是赋予应用代码能力。但更多的常规操作是通过一种无代码的形式去实现的。
我们看到很多早期的软件，如 WinForm、Dreamever，他们都具备低代码平台的特性，但目标都是生成代码给开发人员继续开发。他们通过拖拽等产生代码，间接方式生成网站或者应用，但这类平台最终都没能存活下来。我认为在众多技术及编程语言迭代的要素之外，还有一个重要的因素：每种类型用户都不适用，如果我是一个开发者，我依靠写代码，这种灵活到图灵完备的方式，可以比拖拽配置更灵活快速的实现软件需求。如果我是一个设计师、或者业务人员，我只是在Dreamever或者WinForm 中拖拽是远远不够制作出功能完备的软件的，还是需要开发人员对代码进行修改和配合。
这既是这类平台在选择目标用户上的矛盾性，导致不论是开发人员，还是设计、业务人员都不爱使用这类软件，最终被历史所唾弃。
代码不是最终目标，只是一个生产阶段。我们的目标是业务系统而不是一段代码，低代码平台生成代码这个操作让整个平台变成了非最终价值交付者。并且，当我们生成出代码之后，当开发人员开始对生成出的代码进行编辑之后，很难在使用编辑器去编辑，整个编辑器便失去了其存在的意义。
如上所述，低代码平台生成代码是毫无意义的。低代码本身写代码也会导致目标用户不清，价值交付链条过长等问题。低代码，那么低的那些代码谁去写？开发人员，拖拽配置页面谁去配置？业务人员。如果我们用一个终局视角来看这件事，就会发现这种操作只会是技术演进过程中的一个环节，并非最终形态。低代码的目标是无代码。
低代码平台数据逻辑实现包括两种主要的方式：表单驱动 和 模型驱动。
表单驱动是以页面展示为核心，先有了页面表单，在根据表单项去省城数据结构。而模型驱动的低代码平台是以数据模型的建立为核心，根据不同的数据模型，生成对应的页面表单和各种列表报表。
模型驱动的模式很符合技术思维，我们在写系统之前必须明确的就是业务实体和实体间的关系、交互。以此确定数据模型，数据模型确定好之后，开发接口就是一个工作量的问题。
但对于非技术用户来说，模型驱动的模式非常不直观，一个不懂技术的用户很难理解模型的概念，他只知道我要的数据是什么样子的。最多是选择一个数据类型（字符串、日期、数值）。
低代码平台的实现又可以根据所重点支持的业务进行划分，如：中后台低代码（宜搭）、流程低代码（轻流）和 H5/APP/小程序 低代码（微搭）。前者主要用于做各类企业中后台和业务系统，后者是通过低代码/无代码的能力生成APP或者h5落地页。
这里我们抛开AI能给我们带来的提升不讲。在研发B端工具软件的这段时间里，我发现系统的设计有个明显的矛盾，即功能性和易用性的矛盾。单从工具软件的功能性和易用性两个维度，功能的强大灵活必然要导致软件的易用性变差，学习曲线变得陡峭。而想要学习上手容易，易用性强，那么功能活灵活性势必要大打折扣。要解决这个问题引入AI，如有写厂商支持的AI自动生成图表和页面，是一个解决方案。但目前AI能做到的生成出来的最终成果，实在有限。
功能性的强大对应着学习曲线陡峭，像PS这种专业修图软件和美图秀秀这种大众修图软件相比，学习曲线是不同的。而我们一定要根据平台业务特性选择合理的使用复杂度和学习曲线，这与该平台所能帮助用户达成的价值高低有关，也与平台建设者与使用者之间管理相关。用我们活动页低代码平台来举例，我们面对的是内部用户，关联集团全部业务线活动页需求。用户价值与我们系统强绑定，以此我们可以推广一些复杂功能如 事件流、变量、插件等。但我们也要考虑不要让学习曲线过于陡峭，否则会导致我们的新功能推广起来阻力大、技术服务成本高等问题。
Less is more，简洁的系统设计和完整良好的文档是达成这个目标的关键要素。
道生一、一生二、二生三、三生万物
之前看过一篇不错的文章《工具软件设计哲学》，里面提到一类软件，作者称之为是瑞士军刀式的软件，这类软件就像瑞士军刀一样包含很多小功能、小工具，他们集合起来用来解决某一个业务领域的问题。比如瑞士军刀就用来解决野外生存问题，他所能解决的问题统一在某一个专业的业务领域之内。PhotoShop 就是一个典型的瑞士军刀式的工具软件。
但又是由于这类软件解决的问题过于专业，往往需要的是在该领域的专家才能操作，又由于小工具可以相互组合使用，达成在一开始设计者脑海里，难以想象到的使用方式。所以这类工具软件常常配备一个强大的插件系统。这个插件系统可以让领域专家们自己定义插件解决更复杂更定制化的问题。
我们在内部做低代码平台的时候，也设计了这样一套插件系统。让各个业务方开发人员可以定制拓展低代码编辑器的功能，让我们作为低代码核心开发人员，专注在整个系统机制是设计，而不是某个具体的业务需求。
在我们为自己的平台实现出一套插件系统之后，我们发现整个编辑器平台的功能，几乎都能用插件系统去实现（如复制、粘贴、删除之类）。整个编辑器变得非常轻薄，只需要编辑器框架、插件系统、画布系统、运行时即可，所有复杂的功能和业务代码都可以交给插件。当把这些基础功能都交给插件系统之后，编辑器各个模块之间，自然而然的实现了高内聚低耦合。
只要图灵机可以被实现，就可以用来解决任何可计算问题
虽然现在低代码平台都追求在某一个业务领域发芽生根，但我认为，对于低代码平台来说，灵活性和功能性追求的最高境界是追求达到的图灵完备。
具备图灵完备的低代码平台才能说是广义上的低代码平台，这样他才具备了理论上实现几乎所有计算下问题的能力。
当然这是一个偏向技术侧的说法，从业务角度而言，能实现某一个业务领域的需求，对于这个业务领域来说已经十分有意义了。
2021-01-20