嘀嘀，低代码

互联网里从来是不缺话题的，最近因为低代码平台的价值问题，又在IT圈子里掀起了一阵讨论。说价值前景太含蓄，其实讨论的是——低代码是不是行业毒瘤，以及是否具备商业前景。

首先是InfoQ的编辑置顶了一篇《“行业毒瘤”低代码》，引发业内讨论，文章源自ThoughtWorks的中国区CTO的采访。虽然有些标题党的嫌疑，从作者的采访稿来看，作者对于低代码的发展历程和面临的问题，还是有很清晰的认识，认为目前低代码的流行是源于微服务的发展，并把低代码划分成了三个类型，分别是代码脚本化、企业流程的自动化以及以商业为目的的APaas。当然，作者把第三类的低代码上升到行业价值层面，认为其是行业毒瘤。

接着明道创始人发文《低代码不是行业毒瘤，你才是！》，用于驳斥TW的文章。文章内容火力十足，并要求InfoQ置顶。原文摘录:”我看了全文后，相信这位CTO根本没有动手实践过，至少没有全面研究过，完全在望文生义，自我想象。”通篇看下来，明道的文章有一定的目的是为自家平台夹带私货(商业化低代码平台APaas)，TW的文章更有技术深度，其中提到”低代码的流行是源于微服务的发展”,这个观点是我很赞同的，只有以发展的视角去看待市场和技术，才能把握发展趋势，低代码也不例外。

那什么是低代码平台?

随着互联网的存量时代到来，大中型企业的势必需要兼顾规模化管理和精细化运营，催生了大量的运营类和管理类的中后台运营系统，来满足企业的经营和营销，这类产品和功能的特点很明显，业务要素的组织和管理，说到底就是和业务结合很紧密的增删查改。小型和创业型的企业的需求是另一面，面临支撑业务经营管理的基本功能的快速需要，特点就是业务场景相比前一种会更加通用，比如ERP/CRM/SRM等，但这一类需求，如果因为业务差异，用商业化的产品还不能满足需求，那上低代码平台的作业也会有限，核心目的是减少研发工作量和提升效率。

其实这是两类完全不同要求的应用场景，我认为低代码平台更加适合中型以上企业和团队的中后台系统，这些企业有成型的业务流程和基础系统，以及稳定的IT团队，低代码平台也不是以解决研发工作效能为主，核心目的是产出业务，而非代码。基于这样的判断，那低代码的使用对象也就更加清晰了，运营人员>需求人员>研发人员。

为什么需要低代码平台？

类似数据需求的处理，传统的方式都是运营提报数据需求由运营支撑团队或者数据团队进行处理后反馈，需求传递不清晰、处理链路长，后来有了Ad-hoc的方式，把数据前置到运营人员，进行即席的报表分析。所以功能类需求，是否可以实现这样的方式？

通过低代码平台交付业务功能，提升了业务响应时间，节约了开发的资源，这对IT团队都是正向指标，但理想是美好的，现实总是骨感的。能够把Ad-hoc做得的完善的企业，背后都需要有完善的数据治理机制和经营分析指标体系。曾经尝试过Ad-hoc的方式，数据团队运维了500+主题公共报表，业务团队可以做到1000+的私有报表，涉及到模型和指标调整，对业务和数据团队，都是一场后勤战役。

如何做低代码?

随着SOA/微服务的发展，很多企业和平台对中后台端的支撑系统做了分拆和优化，形成了垂直的业务模块和内聚的业务接口，基于这样的架构特点，让企业有了可以逐步演进的各个业务流程和模块。低代码的再次流行是服务治理的进一步延伸，在前端领域的一次应用，所以也需要站在架构的角度来看待低代码，低代码的背后是什么?

可以把企业的各类中后台系统，类比成一个个白板。除开这些可视的白板，背后还有很多不可视的流程、逻辑、数据。低代码平台就是其中的粘合剂，把流程、逻辑、数据这些要素组织起来，放在白板上。

为什么反复要提微服务?因为通过这些年的三层架构和微服务架构，流程、逻辑、数据已经被灵活的组织了起来。企业内部有各类服务接口、企业之间有稳定的开放平台以及Serverless，这些数据很方便集成到UI的复选、单选、下拉等场景中。

什么要组织? 曾经有一句话，人因为被组织起来才会有力量，这个观点同样适用，这些要素要组织起来才能突显业务价值，通过UI规范化、UI组件化把这些要素组织起来，符合各中台系统的展示、权限、工作流的要求，才能符合业务的预期。

所以低代码背后是什么? 除开平台本身的优良解耦和跨技术栈(前端三座大山)设计，还需要有UI规范管理、UI组件管理、模板脚手架、以及业务流程和服务的支撑。

回到主题

孙子说过，故知战之地，知战之日，则可千里而会战。我们并不能孤立的看待低代码平台本身，认为拖拖拽拽就是低代码，那C#/JAVA的很多拖拽式编程就不会被市场抛弃。从架构的角度来看待低代码平台的业务价值，随着市场变化和技术架构的发展，是不是可以为低代码注入新的活力?从这个角度上讲，我认为低代码平台是有很大应用空间的，但是否有商业价值，这个就需要市场来检验了。