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层的元方法都是不同的。因此，元方法无穷无尽，每上一个维度，他的方法空间的大小也会膨胀一个维度。从一个二维的平面顿时变成了一个三维的空间。因此，抽象的世界比真实世界更复杂，只要咱们不曾停下对真实世界、传统业务的扩张和改造，抽象的空间永远存在，人的思考永远有价值。

结尾来一个相似自举通常的奇妙总结。这篇自己，也是一个元方法。