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