大家应该都知道我从钉钉离职之后就去了飞书的低代码平台,在低代码平台满打满算搞了差不多8个月。
低代码平台又叫作aPaaS,顾名思义,属于PaaS的定位,定位是应用层的基础设施。简单说,就是通过界面拖拉拽,生成各种中等复杂的企业级应用。
8个月在其他公司可能算非常之短,甚至都可以说是花简历了。但是在字节已经超过了平均的工龄7个月。换一个方式来说,如果说在国企的工作寿命是30年的话,那么等于在国企工作了15年。
并且这8个月并不是说慢慢上手了,而是这种高压式的工作方式,所以几乎在前面几周就马上开始投入全新的工作。
比如要解决用户的问题,要串讲代码,还要设计方案,还要做一些新需求。虽然整体上来时间非常紧,但是对于技术和业务的切入程度还是非常快,非常深的。
不过就8个月,我觉得对业务有没有价值不好说,但对我个人来说确实是有了极快的成长的。
这个成长就体现于我怎么样去深层次看待技术。由于我们中国大部分的业务都是应用导向型的,只要用已有的基建来怼出来这个业务就可以了。
你不用管非常良好的设计模式,不用纠缠于底层的数据库的性能,不用做复杂的限流,不用考虑内存CPU的消耗。我们业务都不会碰到这么复杂的技术场景,所以在应用层做东西实际上对自己的技术提升并没有那么大。
但是对于低代码平台来说不一样,我们拥有大量的大客户,大客户场景复杂,数据量极大,需要对复杂的业务进行建模以及底下运行态的能力支撑。
比如,我们碰到最多的的客户就有66个表的关联,单表数据超过了一千万条。
今天我就不会讲低代码的一些细节问题,我今天想跟大家分享一下,为什么低代码平台会这么难做?难做的根本原因是什么?
这里我要给出我自己的一个思考结论,在互联网的产品和技术里面,抽象的层次越高,技术的实现难度就越大。
举个例子。
如果我要设计一个购物网站,难不难?相对不难,因为我只要做一层抽象就可以了,我只要把实体的模型抽象成计算机里面的模型就可以了。
比如一个页面的商品对象,我把它抽象成一个实体的对象,有商品名称,有规格,有价格,有属性。然后我再把这些属性映射到数据库里面去,并且在画出状态和数据流转图,然后就完成了一个建模过程。
剩下的就是代码实现了,那实现相对来说就比较简单。
但是低代码代码平台面对的不是业务本身,而是面对业务的再抽象。换一句话来说,低代码平台要在业务被抽象一层的模型之后再做一层抽象。
那么对于低代码平台来说,它是要构建一套工具和模型来支持任意的模型。所以他就需要在商品订单模型、客户模型、角色模型等多种模型下,抽象出来一套可复用能支持任意模型的模型。
也就是我们称之为元数据。这类元数据就类似于一个按钮,一张图片控件,一个表单。
但这个层面的抽象就非常之难。因为你要考虑到不同的情况,你要解决不同的实体映射,还需要解决这些实体之间的关联关系。而这一切都在你不理解业务的情况下,你要做出一种更加抽象的思考。
同样的在完成数据建模之后的运行态,我们无法直接感知到这个数据它是什么样的一个类型。我们在做一个电商购物交易网站的时候,我们能明确的拿到当前的数据是属于订单还是用户还是商品。
但是对于低代码平台来说,它拿到的是一组无特征的数据,这组无特征的数据,需要根据数据的描述语言才能定位到它到底是什么东西。
所以在这一块我们就没办法能够更加直观的可视化的能拿到业务的上下文,这也给我们排查问题和技术设计带来了非常大的挑战。
再抽象一层,就到了具体的存储、计算、缓存的实现,技术难度又加大了。
所以一旦做一个通用型的东西,它的收益价值一定是越高的,但是它的难度也是越大的。当然这也更考验产品经理和研发的能力。
所以站在业务和技术的层面来说,低代码的难度就在于它是对于业务模型的二次抽象。
当然在这里面我也不得不提一句,一个抽象能力好的程序员,一定是天花板更高的程序员,抽象能力越强,对于事物本质的理解就越到位。