中途这是彭文华的第181篇原创
前些天，陈果大佬发的一篇公众号文章火了。周鹤鸣老板嫌事儿小，攒了个局，拉陈果大佬和任向晖大佬在线约战。二位大佬坐而论道，侃侃而谈了两个小时，最后还不尽兴，在微信群里继续唠。
我反正看热闹的不嫌事儿大，一边吃瓜一边围观。中途顺便还帮周老板加了一把火，在线给陈果总、向晖总提了一个挑事儿的问题。
昨天郑志刚总特意过来找我唠嗑，顺便推荐他们微金时代的低代码BI产品。雷靖总也在群里要低代码的相关资料。
我寻思，一来没聊尽兴，二来手上也有些低代码的资料，那就详细写一写我对低代码的一些认知，顺便给大家一些近期的低代码报告，以供各位大佬参考。
低代码是个新事物？
怎么说呢？其实低代码这个概念早就有了。只不过当时不叫“低代码”，而是叫可视化编程。玩数据的同学都知道ETL这个东西，这就是可视化编程的经典应用。
在没有ETL的时候，我们怎么做数据处理的呢？在传统数据库时代，当然是写存储过程了！上万行的存储过程你见过没有？在大数据时代，就是手写MR、Spark脚本，然后丢到服务器上，按时间进行调度。这简直是灾难！谁用谁知道。
但是有了ETL就不一样了，他们把数据处理的各个基础动作都抽象出来，做成固定的控件。然后用这些基础的控件，进行各种搭配，最终完成一个数据有向无环图的设计。
你看，这是不是跟咱现在说的aPaaS、低代码是一个逻辑？不过这个还不能称之为aPaaS，因为Kettle是个C/S架构的东东，得装一个客户端。
不过，更进一步的东西也有。如果你在CallCenter待过，或者设计过问卷、Leads Follow up的流程，你也会对这样的界面感到熟悉：
这个是AVAYA的外呼流程配置界面，这是比较老的了。我当时在arvato的时候，用的是自研的，已经是B/S架构的了。打开网页就能配置外呼流程。
想改流程就很简单了，在某个控件那边改一下就好了。听起来好像很简单，没啥用啊？
但是！如果没有这个玩意，那你可就惨了！外呼流程改的那叫一个频繁啊！问卷改的就更多了，各种逻辑判断、跳来跳去，得烦死你。有些时候还得两套问卷并存！如果全都得靠人工开发，那得赔死！就问你怎么办！
前两天还有个CallCenter的兄弟跟我讨论问卷数据统一建仓的策略问题呢，他们也对问卷频繁更改的问题烦到要死要死的。
所以CallCenter的问卷、外呼流程配置很早就普及了低代码开发的场景。
低代码为啥火了？
其实，无论是上面的Kettle、AVAYA还是我们当年自研的外呼流程配置产品，可以说是低代码，但是不能说是aPaaS，因为他们低代码有余，而PaaS不足。说白了，就是没有上云啊！
我们当年开发的东西也就我们自己用，别人想用，没门！交钱也不给，这是我们核心竞争力啊。
现在云计算普及了，再加上低代码，好比槟榔加烟，法力无边！这等于就是把当年各大CallCenter的核心竞争力放出来让大家共享了，这能不厉害么？
为了避免广告嫌疑，我就不举低代码厂商的例子了。就说咱现在都用得到的一个场景：做市场调研。各位现在都用啥？问卷星啊！所有应用和数据都在云端。你只需要用手机注册一个账号就行了。
问卷星把所有的场景都提炼出来了，然后把每个动作都抽象成控件，你只需要非常非常简单的几个动作，就能做出非常复杂的问卷逻辑跳转设计。
你别小看问卷星，就这个应用，当年我们客户每年要给我们几十万的IT维护费的！
所以，你明白了么？低代码就在你身边，早已普及了好么？
而之所以变火了，并不是在炒作新概念，而是这个市场真的已经发育成熟了，可以摘来吃了。
作为享受十多年低代码红利的我，那必须力推低代码！奥利给！
低代码好用吗？
当然了！必须好用！要不你自己开发一个问卷，我用问卷星设计一个。咱俩比比速度？我10分钟完事。你呢？给你10个人，一个礼拜，看能比得过我不？
低代码的核心就是对各种现有场景通用功能的抽象。抽象成一个个控件之后，我们就能用这些控件完成我们想要的一些业务需求了。对于一些流程设计类的应用场景，那真的是如砍瓜切菜一般，非常好用。
那具体是哪些场景呢？
我在会议室挑起二位战火的问题就是这个。当时向总po了一张图，上面总结了6个应用场景：
其实，在我看来，就只有一个场景，就是信息流转的流程设计。所有这个场景，全部适用。什么投票、问卷、数据采集、业务流程、自动化工作流、审批、表单、报销、合同等等。
所以你看，为啥钉钉对低代码这么上心？因为低代码完全适用办公环境啊！全都是固定信息流啊！
我们把这些办公中做的各种操作抽象出来，做成控件。公司的HR、财务上去随便点两下，人事审批流程就做好了，财务报销流程也就弄好了。还要OA干啥？
钉钉现在几乎把各种OA软件全干掉了，包括早就是低代码开发的泛微。因为泛微再便宜，好歹还要装个软件。钉钉只需要开个账号就行了。
那我们All in低代码？
emmmm...低代码还是有他的核心问题的。最致命的问题就是这些数据怎么办。作为数据工作者，我是很在意的。
你想啊，低代码想要通用，后面的程序怎么设计？控件是通用的吧？数据存储肯定也得是即时生成的吧？要不某种相对固定的能容纳所有结构的也行。
但是这么做，必然导致一个问题，就是所有表、字段都是机器定义的 。我们无法从数据库层面直接解读。也就是说，低代码创造的数据，我们无法或者说非常非常难以进行数据治理。因为那些表名、字段名根本没人能读懂。
虽然有些厂子做了一些业务语义和表、字段名之间的映射，但是即便是这样，那也对本来就非常难搞的数据治理增加了难度。
所以我作为用户是非常喜欢低代码的，但是作为数据工作者，我是非常非常讨厌低代码的。因为低代码意味着数据治理失控。
正所谓低代码一时爽，数据治理火葬场。
总结
低代码概念早就有了！Kettle、AVAYA等都是！aPaaS也早就有了！问卷星就是！ 不是新词！不是新概念！不是炒作！
低代码非常好，跟乐高一样，你想要啥都能给你搭出来。效率之高，我一个抵你100个。雷老板的“专注极致口碑快”，低代码占全了，你说怎么阻挡？所以，低代码是趋势，不要对抗趋势，要顺应趋势。
低代码最大的阻碍是数据治理，如果不不需要治理就无所谓了。
扩展阅读：《头豹等三份低代码行业研究报告》
