搭架子是腦垂體在放煙花
俗話說吃多少飯，走多少路，上學的時候捧着《設計模式》就想睡覺，現在輪子看得多了，自然有心領神會之感。搭架子就像談哲學，如高山流水，遇彎則急、遇潭則深。我印象最深的是一次酒過三巡，一位德高望重的前輩講釋迦牟尼的故事：有人問釋迦牟尼”恆河的沙礫有多少？“，釋迦牟尼答：“恆河的沙礫比銀河的星星還要多。”對科普過的我們這一比喻看似普通尋常，但是在那時候對宇宙根本沒有多少認識的年代，能做出這樣的判斷，是需要怎樣的大智慧才能辦到？
搭架子就是一個思考恆河沙礫數量的過程，不應被DAL、MVC、MVP、MVVM、DDD、充血、貧血這些術語固化，這些是規范、是交流語言（DDD里面還專門討論了這個事），目的是為了讓你或者團隊的其他人能夠看懂你在干什么（如PHP中的PSR-X規范一樣），只是告訴你“數沙礫的步驟”；選擇用哪個規范來完成，才是思考恆河沙礫數量的過程（比如你直接復制一個MVP的項目模板作為架子藍本，為什么要復制一個藍本直接用，因為你心里有數這樣做最快、最省事，這就是一個思考過程）。
再舉個例子，劍法巔峰講究“合一”境界，人劍合一、見招拆招、凌波微步，忘記所有劍譜和步數，心指劍到，唯我不破。搭架子，是“人劍合一”的過程，你可能會畫草圖、會寫需求文檔，但都是在心中刻畫整個輪廓；寫代碼，是在重演劍譜，因為劍譜你已經擺了幾百盤，你知道listview需要adapter、tableview需要算高度；用輪子，是在見招拆招，你可以用Glide或者SDWebImage、或者干脆直接用AFNetworking自帶的圖片擴展。
架子遷移，是從無序的代碼結構中進行提煉和總結，以MVP、MVVM等思路對代碼進行重構。搭一個架子根本不是性能，而是為了體現更好的代碼規范和功能擴展（白話就是什么代碼寫到哪個文本文件里面，如Presenter里面放交互代碼）。
討論之前先明確幾個思路
DDD里面特別提到過一個觀點我非常贊同--UBIQUITOUS LANGUAGE(通用語言)，就是首先要理清楚我們到底是在討論什么，這樣才不會誤會，思想才能連貫。比如我說“蒼老師”，你我都知道我們在談什么；但我要是說“陸家嘴”，你以為我是在說那個視頻，我其實是在說一個地名。這里套用這一概念，先說說我搭架子的幾個思路。
1.不要用力過度。一個幾千萬把塊錢的項目，就別思考用DDD（DDD是我見過最高深晦澀的架子思路）把業務拆分成領域然后還要設計接口和工廠了。一個基礎架子的代碼量都比你實際功能寫的代碼量多。 2.不要被MVP、MVVM唬到了。舉個例子，之前你可能會用一個BaseXXX把社交分享、界面初始化的代碼寫在里面，XXX繼承該類，然后就只需要把某個按鈕的邏輯寫出來，這樣一個文件里面的代碼行數就降下來了，讀起來就清爽了。MVP、MVVM干的就是這種事，如出一轍，只是更規范而已。 3.設計模式不是架子。同樣是開發思路，但設計模式是針對某一邏輯功能的實現策略。比如社交分享，你可以用工廠模式實現QQ、微信、微博（都有個成功、失敗的狀態，只是發送的數據不一樣），代碼寫在哪個文件里面，放在哪個包里，就是架子考慮的事。 4. 現在火的不行的RxXXXXXX不是架子，是輪子（更直白的說是技術網紅找優越感的罩杯，MVVM也是，這些在.NET3.5時代就玩膩的東西，拿來還當寶了:P）。響應式編程值得學習，但沒有達到完全取代Handler的高度。現在的架子哪里不好了
APP到底要不要用一種模式來搭架子，是一個需要權衡的想法。APP說白了和Winform一樣就是個展示層（Presentation），做過Winform的都知道，一個DAL三層模式就足以勝任大部分工具軟件的需要了。所以沒有必要把APP開發想象的那么高深莫測，就是一個網絡訪問-》數據讀取-》數據顯示的過程，用包或者Xcode里面的group區分業務模塊，就是一種簡單並且特別實用的架子。
上圖就是一個典型ios架子，通用工具類沒畫出來，但應該可以理解（比如時間處理）。一個模塊為一個Group（如首頁），首頁模塊的代碼按MVC分離，所有功能邏輯全部放在Controller中，有不妥么？沒有任何不妥，功能一個不落可以實現，但.M文件就顯得太臃腫了。
上圖做了簡單的剝離，把網絡通信模塊從Controller中取出來，放在Manager中。Controller的.M文件是不是就感覺干凈多了？其實還可以繼續剝離，把TableViewCell的數據綁定放到Model中去，把數據庫緩存等寫到一個叫Task的文件中去。從我讀過的不下10個開源項目看來，到這一步，就是現在最常見的架子結構了，代碼復雜程度可以接受、架子伸縮自如，其他模塊只是復制加粘貼的問題了。
對Android來講，架子可以說一模一樣，只是多了一個adapter，Controller變成了Activity或者Fragment。從功能實現上講，有問題嗎？也沒有任何問題。那么為什么要考慮用MVVM或者MVP模式呢？如果你有強迫症，喜歡把MM豆根據顏色歸類；或者隨着功能的增加或參與人員的增加，你會慢慢覺得Contoller中寫的代碼開始亂套找不到你想要的東西，直覺會告訴你，是時候需要一套基於單一原則的架子來重構項目了。
架子就像寫八股文
在前文討論了UBIQUITOUS LANGUAGE(通用語言)這一概念，常見關鍵字如Manager、Domain、Service、Biz、Helper，其實文件里面寫的代碼干的都是一碼事，但都是不同架子模型中的術語（如Domain是DDD中的術語）。如果是個團隊，即使見多識廣，也不推薦混淆使用術語，這樣容易造成困惑，有些事情還是較真一點比較好。另外，各種架子需要基礎代碼或文件來搭建，比如MVP模式中有一個XXXContract文件，定義行為接口。這些代碼會增加工作量，但卻值得老老實實的創建，因為這些架子基礎代碼可以更好的執行邏輯隔離和單一原則行為，讓代碼更好理解。
所以搭架子就像寫八股文，就像寫論文一樣，不是搞藝術創作，你不是詩人。規范的目的就是為了層次清晰，當你習慣架子規范后，你在看到文件名的時候就心中有數，應該如何繼續如何繼續開發了。
接下來的文章
我在看架子的時候一直對“業務邏輯和功能邏輯要分離”等等很晦澀的話感到困惑，接下來的文章我都希望能通過實例代碼讓你搞明白這些究竟是在講些什么東西。全文以我開源的社交APP“獨白故事”及多個github開源項目為代碼藍本進行解釋，總結一下自己對架子的理解，順便也把獨白故事更新一下：）