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層的元方法都是不同的。因此，元方法無窮無盡，每上一個維度，他的方法空間的大小也會膨脹一個維度。從一個二維的平面頓時變成了一個三維的空間。因此，抽象的世界比真實世界更復雜，只要咱們不曾停下對真實世界、傳統業務的擴張和改造，抽象的空間永遠存在，人的思考永遠有價值。

結尾來一個相似自舉通常的奇妙總結。這篇自己，也是一個元方法。