分类: 未分类

Meta of Meta 求元方法递归

首先,我们解决一个问题,我们有了第一个方法。然后,我们想解决包含这个问题的一类问题,我们总结一个元方法。然后,我们想知道怎么样找到一类问题的方法的方法,这是就是元方法的元方法。或者说,元元方法。这样的一个不断上溯的过程,我称之为求元方法递归。

从互联网业务-编程实际场景举例子,飞猪,大家都知道,阿里的在线旅行电商销售网站。飞猪最开始只是照搬了淘宝的下单组件,这个下单组件针对于一般商品的下单流程,他只能让用户填写收货地址和数量和品类。对于飞猪的签证业务来说,这样的下单组件起不了帮助。因为签证业务需要收集用户的关键护照信息,那么就只能靠客服一对一的聊天和用户确认信息。运营收集到行业商家的痛点,反馈给产品经理,产品经理思考这个需求点的合理性和整体流程,给到技术开发排期上线。好,至此为止,第一层 meta 元方法产生了。因为在这个新版的为签证业务定制的下单组件,用一个方法解决了一类问题的麻烦。

那么我们该如何衡量这个元方法的业务/技术收益?元方法的收益应该是=(单个收益*适用范围-推广成本)。

继续思考,元元方法的产生。我们来讨论第二层是怎么产生的。第二层,如果有很多个类似签证的业务方,比如邮轮,机票,酒店,电话卡,都要定制他们自己的下单组件进来,怎么办?核心思想就是解耦,但是又不仅仅是解耦。比如从解耦层次上,可能是只做数据层解耦,样式定死,支持一部分样式相同的组件的快速部署。又可能是样式、数据同时解耦,还可能是组件级别解耦,业务方根据协议生成组件,交付下单页面渲染布局。

这里可以插一句,内聚/解耦的思想,是业务开发的核心方法论。业务开发面对底层开发在跟你炫耀 OpenGL,xx 算法模型,xx 编译原理的时候,可以先说你说的我也略懂,然后再问一句,那么,你懂xx业务解耦/组件化/动态布局/行业赋能/业务大脑吗?

好,到第二层元元方法就为止了吗?其实不止。必然会有第三层,元元元方法,比如解耦要解到什么地步。假设你确定了这个下单页面可以解耦到组件层级,那明年呢?明年组件层级够用吗?这是时间维度。空间维度呢?换商品详情业务,解耦到什么层级呢?假设我们说商品详情业务可以解耦到数据层级,那么为什么下单可以解耦到组件层级,商品详情业务只能解耦到数据层级?能不能创建出一个推论模式,通过几个条件来判断一个业务究竟能解耦到哪个层级?

前面说的都是业务维度,再从技术一点的维度来说,移动 App 页面开发总共可以归纳为几种形式的解耦,这些解耦各自有几种技术方案来实现。能否把解耦这事情也抽象成一个方案,使得一个业务只需要很低的开发/接入成本就可以切换成解耦型方案?事实上,Weex/Rax/H5也基本等同于是一个直接可插入的组件级别解耦方案了。只是这种大型通用的技术方案,已经不能称之为技术方案了,大家习惯性地把他看成了一个可以吃十几年饭的技术栈。但当我们缩小通用性领域,提高对某一类问题的专业度和适用度的时候,我们必然可以得到一个好的行业解决方案。

第四层…好了,不说了,事实上抽象到第三层已经适用大多数场景了。但这并不意味着,第三层的元元元方法很少,事实上,很多。当我们在讨论 n+1 层的元方法的时候,我们必然是舍弃了 n 层中的一些信息,来获取
n1,n2,n3….中的一些公有的共同点。那么,舍弃A、B、C,取 D,和舍弃A、C、D,取 B,他们得到的 n+1层的元方法都是不一样的。所以,元方法无穷无尽,每上一个维度,他的方法空间的大小也会膨胀一个维度。从一个二维的平面顿时变成了一个三维的空间。所以,抽象的世界比真实世界更复杂,只要我们未曾停下对真实世界、传统业务的扩张和改造,抽象的空间永远存在,人的思考永远有价值。

结尾来一个类似自举一般的奇妙总结。这篇本身,也是一个元方法。