|
緣由 之前安居客iOS app的第二版架構(gòu)大部分內(nèi)容是我做的，期間有總結(jié)了一些經(jīng)驗。在將近一年之后，前同事zzz在微信朋友圈上發(fā)了一個問題：假如問你一個iOS or Android app的架構(gòu)，你會從哪些方面來說呢？ 當(dāng)時看到這個問題正好在乘公車回家的路上，閑來無聊就答了一把。在zzz在微信朋友圈上追問了幾個問題之后，我覺得有必要以文章形式專門來講一些個人見解。 其實對于iOS客戶端應(yīng)用的架構(gòu)來說，復(fù)雜度不亞于服務(wù)端，但側(cè)重點和入手點卻跟服務(wù)端不太一樣。比如客戶端應(yīng)用就不需要考慮類似C10K的問題，正常的app就根本不需要考慮。 這系列文章我會主要專注在iOS應(yīng)用架構(gòu)方面，很多方案也是基于iOS技術(shù)棧的特點而建立的。因為我個人不是很喜歡寫Java，所以Android這邊的我就不太了解了。如果你是Android開發(fā)者，你可以側(cè)重看我提出的一些架構(gòu)思想，畢竟不管做什么，思路是相通的，實現(xiàn)手段不同罷了。 當(dāng)我們討論客戶端應(yīng)用架構(gòu)的時候，我們在討論什么？ 其實市面上大部分應(yīng)用不外乎就是顛過來倒過去地做以下這些事情：
簡單來說就是調(diào)API，展示頁面，然后跳轉(zhuǎn)到別的地方再調(diào)API，再展示頁面。 那這有什么好架構(gòu)的？ 非也，非也。 ---- 包不同 《天龍八部》 App確實就是主要做這些事情，但是支撐這些事情的基礎(chǔ)，就是做架構(gòu)要考慮的事情：
上面幾點是針對App說的，下面還有一些是針對團(tuán)隊說的：
一時半會兒我還是只能想到上面這三點，事實上應(yīng)該還會有很多，這里就不一一列舉了。 所以當(dāng)我們討論客戶端應(yīng)用架構(gòu)的時候，我們討論的差不多就是這些問題。 這系列文章要回答哪些問題？ 這系列文章主要是回答以下這些問題：
本文要回答那些問題？ 上面細(xì)分出來的四個問題，我會分別在四篇文章里面寫。那么這篇文章就是來講一些通識啥的，也是開個坑給大家討論通識問題的。 架構(gòu)設(shè)計的方法 所有事情最難的時候都是開始做的時候，當(dāng)你開始著手設(shè)計并實現(xiàn)某一層的架構(gòu)乃至整個app的架構(gòu)的時候，很有可能會出現(xiàn)暫時的無從下手的情況。以下方法論是我這些年總結(jié)出來的經(jīng)驗，每個架構(gòu)師也一定都有一套自己的方法論，但一樣的是，不管你采用什么方法，全局觀、高度的代碼審美能力、靈活使用各種設(shè)計模式一定都是貫穿其中的。歡迎各位在評論區(qū)討論。 第一步：搞清楚要解決哪些問題，并找到解決這些問題的充要條件 你必須得清楚你要做什么，業(yè)務(wù)方希望要什么。而不是為了架構(gòu)而架構(gòu)，也不是為了體驗新技術(shù)而改架構(gòu)方案。以前是MVC，最近流行MVVM，如果過去的MVC是個好架構(gòu)，沒什么特別大的缺陷，就不要推倒然后搞成MVVM。 關(guān)于充要條件我也要說明一下，有的時候系統(tǒng)提供的函數(shù)是需要額外參數(shù)的，比如read函數(shù)。還有翻頁的時候，當(dāng)前頁碼也是充要條件。但對于業(yè)務(wù)方來說，這些充要條件還能夠再縮減。 比如read，需要給出file descriptor，需要給出buf，需要給出size。但是對于業(yè)務(wù)方來說，充要條件就只要file descriptor就夠了。再比如翻頁，其實業(yè)務(wù)方并不需要記錄當(dāng)前頁號，你給他暴露一個loadNextPage這樣的方法就夠了。 搞清楚對于業(yè)務(wù)方而言的真正充要條件很重要！這決定了你的架構(gòu)是否足夠易用。另外，傳的參數(shù)越少，耦合度相對而言就越小，你替換模塊或者升級模塊所花的的代價就越小。 第二步：問題分類，分模塊 這個不用多說了吧。 第三步：搞清楚各問題之間的依賴關(guān)系，建立好模塊交流規(guī)范并設(shè)計模塊 關(guān)鍵在于建立一套統(tǒng)一的交流規(guī)范。這一步很能夠體現(xiàn)架構(gòu)師在軟件方面的價值觀，雖然存在一定程度上的好壞優(yōu)劣（比如胖Model和瘦Model），但既然都是架構(gòu)師了，基本上是不會設(shè)計出明顯很爛的方案的，除非這架構(gòu)師還不夠格。所以這里是架構(gòu)師價值觀輸出的一個窗口，從這一點我們是能夠看出架構(gòu)師的素質(zhì)的。 另外要注意的是，一定是建立一套統(tǒng)一的交流規(guī)范，不是兩套，不是多套。你要堅持你的價值觀，不要搖擺不定。要是搞出各種五花八門的規(guī)范出來，一方面有不切實際的炫技嫌疑，另一方面也會帶來后續(xù)維護(hù)的災(zāi)難。 第四步：推演預(yù)測一下未來可能的走向，必要時添加新的模塊，記錄更多的基礎(chǔ)數(shù)據(jù)以備未來之需 很多稱職的架構(gòu)師都會在這時候考慮架構(gòu)未來的走向，以及考慮做完這一輪架構(gòu)之后，接下來要做的事情。一個好的架構(gòu)雖然是功在當(dāng)代利在千秋的工程，但絕對不是一個一勞永逸的工程。軟件是有生命的，你做出來的架構(gòu)決定了這個軟件它這一生是坎坷還是幸福。 第五步：先解決依賴關(guān)系中最基礎(chǔ)的問題，實現(xiàn)基礎(chǔ)模塊，然后再用基礎(chǔ)模塊堆疊出整個架構(gòu) 這一步也是驗證你之前的設(shè)計是否合理的一步，隨著這一步的推進(jìn)，你很有可能會遇到需要對架構(gòu)進(jìn)行調(diào)整的情況。這個階段一定要吹毛求疵高度負(fù)責(zé)地去開發(fā)，不要得過且過，發(fā)現(xiàn)架構(gòu)有問題就及時調(diào)整。否則以后調(diào)整的成本就非常之大了。 第六步：打點，跑單元測試，跑性能測試，根據(jù)數(shù)據(jù)去優(yōu)化對應(yīng)的地方 你得用這些數(shù)據(jù)去向你的boss邀功，你也得用這些數(shù)據(jù)去不斷調(diào)整你的架構(gòu)。 總而言之就是要遵循這些原則：自頂向下設(shè)計（1，2，3，4步），自底向下實現(xiàn)（5），先測量，后優(yōu)化（6）。 什么樣的架構(gòu)師是好架構(gòu)師？
什么樣的架構(gòu)叫好架構(gòu)？
以上是我判斷一個架構(gòu)是不是好架構(gòu)的標(biāo)準(zhǔn)，這是根據(jù)重要性來排列的?？蛻舳思軜?gòu)跟服務(wù)端架構(gòu)要考慮的問題和側(cè)重點是有一些區(qū)別的。下面我會針對每一點詳細(xì)講解一下： 代碼整齊，分類明確，沒有common，沒有core 代碼整齊是每一個工程師的基本素質(zhì)，先不說你搞定這個問題的方案有多好，解決速度有多快，如果代碼不整齊，一切都白搭。因為你的代碼是要給別人看的，你自己也要看。如果哪一天架構(gòu)有修改，正好改到這個地方，你很容易自己都看不懂。另外，破窗理論提醒我們，如果代碼不整齊分類不明確，整個架構(gòu)會隨著一次一次的拓展而越來越混亂。 分類明確的字面意思大家一定都了解，但還有一個另外的意思，那就是：不要讓一個類或者一個模塊做兩種不同的事情。如果有類或某模塊做了兩種不同的事情，一方面不適合未來拓展，另一方面也會造成分類困難。 不要搞Common，Core這些東西。每家公司的架構(gòu)代碼庫里面，最惡心的一定是這兩個名字命名的文件夾，我這么說一定不會錯。不要開Common，Core這樣的文件夾，開了之后后來者一定會把這個地方搞得一團(tuán)糟，最終變成Common也不Common，Core也不Core。要記住，架構(gòu)是不斷成長的，是會不斷變化的。不是每次成長每次變化，都是由你去實現(xiàn)的。如果真有什么東西特別小，那就索性為了他單獨開辟一個模塊就好了，小就小點，關(guān)鍵是要有序。 關(guān)于這一條，后面還會詳細(xì)論述。 不用文檔，或很少文檔，就能讓業(yè)務(wù)方上手 誰特么會去看文檔啊，業(yè)務(wù)方他們已經(jīng)被產(chǎn)品經(jīng)理逼得很忙了。所以你要盡可能讓你的API名字可讀性強，對于iOS來說，objc這門語言的特性把這個做到了極致，函數(shù)名長就長一點，不要緊。 好的函數(shù)名： - (NSDictionary *)exifDataOfImage:(UIImage *)image atIndexPath:(NSIndexPath *)indexPath; 壞的函數(shù)名： - (id)exifData:(UIImage *)image position:(id)indexPath callback:(id<ErrorDelegate>)delegate; 為什么壞？
思路和方法要統(tǒng)一，盡量不要多元 解決一個問題會有很多種方案，但是一旦確定了一種方案，就不要在另一個地方采用別的方案了。也就是做架構(gòu)的時候，你得時刻記住當(dāng)初你決定要處理這樣類型的問題的方案是什么，以及你的初衷是什么，不要搖擺不定。 另外，你當(dāng)初設(shè)立這個模塊一定是有想法有原因的，要記錄下你的解決思路，不要到時候換個地方你又靈光一現(xiàn)啥的，引入了其他方案，從而導(dǎo)致異構(gòu)。 要是一個框架里面解決同一種類似的問題有各種五花八門的方法或者類，我覺得做這個架構(gòu)的架構(gòu)師一定是自己都沒想清楚就開始搞了。 沒有橫向依賴，萬不得已不出現(xiàn)跨層訪問 沒有橫向依賴是很重要的，這決定了你將來要對這個架構(gòu)做修補所需要的成本有多大。要做到?jīng)]有橫向依賴，這是很考驗架構(gòu)師的模塊分類能力和是否熟悉業(yè)務(wù)的。 跨層訪問是指數(shù)據(jù)流向了跟自己沒有對接關(guān)系的模塊。有的時候跨層訪問是不可避免的，比如網(wǎng)絡(luò)底層里面信號從2G變成了3G變成了4G，這是有可能需要跨層通知到View的。但這種情況不多，一旦出現(xiàn)就要想盡一切辦法在本層搞定或者交給上層或者下層搞定，盡量不要出現(xiàn)跨層的情況?？鐚釉L問同樣也會增加耦合度，當(dāng)某一層需要整體替換的時候，牽涉面就會很大。 對業(yè)務(wù)方該限制的地方有限制，該靈活的地方要給業(yè)務(wù)方創(chuàng)造靈活實現(xiàn)的條件 把這點做好，很依賴于架構(gòu)師的經(jīng)驗。架構(gòu)師必須要有能力區(qū)分哪些情況需要限制靈活性，哪些情況需要創(chuàng)造靈活性。比如對于Core Data技術(shù)棧來說，ManagedObject理論上是可以出現(xiàn)在任何地方的，那就意味著任何地方都可以修改ManagedObject，這就導(dǎo)致ManagedObjectContext在同步修改的時候把各種不同來源的修改同步進(jìn)去。這時候就需要限制靈活性，只對外公開一個修改接口，不暴露任何ManagedObject在外面。 如果是設(shè)計一個ABTest相關(guān)的API的時候，我們又希望增加它的靈活性。使得業(yè)務(wù)方不光可以通過Target-Action的模式實現(xiàn)ABtest，也要可以通過Block的方式實現(xiàn)ABTest，要盡可能滿足靈活性，減少業(yè)務(wù)方的使用成本。 易測試易拓展 老生常談，要實現(xiàn)易測試易拓展，那就要提高模塊化程度，盡可能減少依賴關(guān)系，便于mock。另外，如果是高度模塊化的架構(gòu)，拓展起來將會是一件非常容易的事情。 保持一定量的超前性 這一點能看出架構(gòu)師是否關(guān)注行業(yè)動態(tài)，是否能準(zhǔn)確把握技術(shù)走向。保持適度的技術(shù)上的超前性，能夠使得你的架構(gòu)更新變得相對輕松。 另外，這里的超前性也不光是技術(shù)上的，還有產(chǎn)品上的。誰說架構(gòu)師就不需要跟產(chǎn)品經(jīng)理打交道了，沒事多跟產(chǎn)品經(jīng)理聊聊天，聽聽他對產(chǎn)品未來走向的暢想，你就可以在合理的地方為他的暢想留一條路子。同時，在創(chuàng)業(yè)公司的環(huán)境下，很多產(chǎn)品需求其實只是為了趕產(chǎn)品進(jìn)度而產(chǎn)生的妥協(xié)方案，最后還是會轉(zhuǎn)到正軌的。這時候業(yè)務(wù)方可以不實現(xiàn)轉(zhuǎn)到正規(guī)的方案，但是架構(gòu)這邊，是一定要為這種可預(yù)知的改變做準(zhǔn)備的。 接口少，接口參數(shù)少 越少的接口越少的參數(shù)，就能越降低業(yè)務(wù)方的使用成本。當(dāng)然，充要條件還是要滿足的，如何在滿足充要條件的情況下盡可能地減少接口和參數(shù)數(shù)量，這就能看出架構(gòu)師的功力有多深厚了。 高性能 為什么高性能排在最后一位？ 高性能非常重要，但是在客戶端架構(gòu)中，它不是第一考慮因素。原因有下：
但是！不重要不代表用不著去做，關(guān)于性能優(yōu)化的東西，我會對應(yīng)放到各系列文章里面去。比如網(wǎng)絡(luò)層優(yōu)化，那就會在網(wǎng)絡(luò)層方案的那篇文章里面去寫，對應(yīng)每層架構(gòu)都有每層架構(gòu)的不同優(yōu)化方案，我都會在各自文章里面一一細(xì)說。 關(guān)于架構(gòu)分層？ 昨晚上朋友看了這篇文章之后說，看到你這個題目本來我是期望看到關(guān)于架構(gòu)分層相關(guān)的東西的，但是你沒寫。 嗯，確實沒寫，當(dāng)時沒寫的原因是感覺這個沒什么好寫的。前面談?wù)摰郊軜?gòu)的方法的時候，關(guān)于問題分類分模塊這一步時，架構(gòu)分層也屬于這一部分，給我一筆帶過了。 既然朋友提出來了這個問題，我想可能大家關(guān)于這個也會有一些想法和問題，那么我就在這兒講講吧。 其實分層這種東西，真沒啥技術(shù)含量，全憑架構(gòu)師的經(jīng)驗和素質(zhì)。 我們常見的分層架構(gòu)，有三層架構(gòu)的：展現(xiàn)層、業(yè)務(wù)層、數(shù)據(jù)層。也有四層架構(gòu)的：展現(xiàn)層、業(yè)務(wù)層、網(wǎng)絡(luò)層、本地數(shù)據(jù)層。這里說三層、四層，跟TCP/IP所謂的五層或者七層不是同一種概念。再具體說就是：你這個架構(gòu)在邏輯上是幾層那就幾層，具體每一層叫什么，做什么，沒有特定的規(guī)范。這主要是針對模塊分類而言的。 也有說MVC架構(gòu)，MVVM架構(gòu)的，這種層次劃分，主要是針對數(shù)據(jù)流動的方向而言的。 在實際情況中，針對數(shù)據(jù)流動方向做的設(shè)計和針對模塊分類做的設(shè)計是會放在一起的，也就是說，一個MVC架構(gòu)可以是四層：展現(xiàn)層、業(yè)務(wù)層、網(wǎng)絡(luò)層、本地數(shù)據(jù)層。 那么，為什么我要說這個？ 大概在五六年前，業(yè)界很流行三層架構(gòu)這個術(shù)語。然后各種文檔資料漫天的三層架構(gòu)，并且喜歡把它與MVC放在一起說，MVC三層架構(gòu)/三層架構(gòu)MVC，以至于很多人就會認(rèn)為三層架構(gòu)就是MVC，MVC就是三層架構(gòu)。其實不是的。三層架構(gòu)里面其實沒有Controller的概念，而且三層架構(gòu)描述的側(cè)重點是模塊之間的邏輯關(guān)系。MVC有Controller的概念，它描述的側(cè)重點在于數(shù)據(jù)流動方向。 好，為什么流行起來的是三層架構(gòu)，而不是四層架構(gòu)或五層架構(gòu)？ 因為所有的模塊角色只會有三種：數(shù)據(jù)管理者、數(shù)據(jù)加工者、數(shù)據(jù)展示者，意思也就是，籠統(tǒng)說來，軟件只會有三層，每一層扮演一個角色。其他的第四層第五層，一般都是這三層里面的其中之一分出來的，最后都能歸納進(jìn)這三層的某一層中去，所以用三層架構(gòu)來描述就比較普遍。 那么我們怎么做分層？ 應(yīng)該如何做分層，不是在做架構(gòu)的時候一開始就考慮的問題。雖然我們要按照自頂向下的設(shè)計方式來設(shè)計架構(gòu)，但是一般情況下不適合直接從三層開始。一般都是先確定所有要解決的問題，先確定都有哪些模塊，然后再基于這些模塊再往下細(xì)化設(shè)計。然后再把這些列出來的問題和模塊做好分類。分類之后不出意外大多數(shù)都是三層。如果發(fā)現(xiàn)某一層特別龐大，那就可以再拆開來變成四層，變成五層。 舉個例子：你要設(shè)計一個即時通訊的服務(wù)端架構(gòu)，怎么分層？ 記住，不要一上來就把三層架構(gòu)的規(guī)范套上去，這樣做是做不出好架構(gòu)的。 你要先確定都需要解決哪些問題。這里只是舉例子，我隨意列出一點意思意思就好了：
解決第一個問題需要一個鏈接管理模塊，鏈接管理模塊一般是通過鏈接池來實現(xiàn)。 解決第二個問題需要有一個數(shù)據(jù)交換模塊，從A接收來的數(shù)據(jù)要給到B，這個事情由這個模塊來做。 解決第三個問題需要有個數(shù)據(jù)庫，如果是服務(wù)于大量用戶，那么就需要一個緩沖區(qū)，只有當(dāng)需要存儲的數(shù)據(jù)達(dá)到一定量時才執(zhí)行寫操作。 解決第四個問題可以有幾種解決方案，一個是集群中有那么幾臺服務(wù)器作為尋路服務(wù)器，所有尋路的服務(wù)交給那幾臺去做，那么你需要開發(fā)一個尋路服務(wù)的Daemon。或者用廣播方式尋路，但如果尋路頻次非常高，會造成集群內(nèi)部網(wǎng)絡(luò)負(fù)載特別大。這是你要權(quán)衡的地方，目前流行的思路是去中心化，那么要解決網(wǎng)絡(luò)負(fù)載的問題，你就可以考慮配置一個緩存。 于是我們有了這些模塊： 鏈接管理、數(shù)據(jù)交換、數(shù)據(jù)庫及其配套模塊、尋路模塊 做到這里還遠(yuǎn)遠(yuǎn)沒有結(jié)束，你要繼續(xù)針對這四個模塊繼續(xù)往下細(xì)分，直到足夠小為止。但是這里只是舉例子，所以就不往下深究了。 另外，我要提醒你的是，直到這時，還是跟幾層架構(gòu)毫無關(guān)系的。當(dāng)你把所有模塊都找出來之后，就要開始整理你的這些模塊，很有可能架構(gòu)圖就是這樣：
然后這些模塊分完之后你看一下圖，嗯，1、2、3，一共三層，所以那就是三層架構(gòu)啦。在這里最消耗腦力最考驗架構(gòu)師功力的地方就在于：找到所有需要的模塊， 把模塊放在該放的地方 這個例子側(cè)重點在于如何分層，性能優(yōu)化、數(shù)據(jù)交互規(guī)范和包協(xié)議、數(shù)據(jù)采集等其他一系列必要的東西都沒有放進(jìn)去，但看到這里，相信你應(yīng)該了解架構(gòu)師是怎么對待分層問題的了吧？ 對的，答案就是沒有分層。所謂的分層都是出架構(gòu)圖之后的事情了。所以你看別的架構(gòu)師在演講的時候，上來第一句話差不多都是："這個架構(gòu)分為以下幾層..."。但考慮分層的問題的時機(jī)絕對不是一開始就考慮的。另外，模塊一定要把它設(shè)計得獨立性強，這其實是門藝術(shù)活。 另外，這雖然是服務(wù)端架構(gòu)，但是思路跟客戶端架構(gòu)是一樣的，側(cè)重點不同罷了。之所以不拿客戶端架構(gòu)舉例子，是因為這方面的客戶端架構(gòu)蘋果已經(jīng)幫你做好了絕大部分事情，沒剩下什么值得說的了。 關(guān)于Common文件夾？ 在原文的評論區(qū)MatrixHero提到一點：
這是針對我前面提出的不要Common，不要Core而言的，為什么我建議大家不要開Common文件夾？我打算分幾種情況給大家解釋一下。 一般情況下，我們都會有一些屬于這個項目的公共類，比如取定位坐標(biāo)，比如圖像處理。這些模塊可能非常小，就h和m兩個文件。單獨拎出來成為一個模塊感覺不夠格，但是又不屬于其他任何一個模塊。于是大家很有可能就會把它們放入Common里面，我目前見到的大多數(shù)工程和大多數(shù)文檔里面的代碼都喜歡這么做。在當(dāng)時來看，這么做看不出什么問題，但關(guān)鍵在于：軟件是有生命，會成長的。當(dāng)時分出來的小模塊，很有可能會隨著業(yè)務(wù)的成長，逐漸發(fā)展成大模塊，發(fā)展成大模塊后，可以再把它從Common移出來單獨成立一個模塊。這個在理論上是沒有任何問題的，然而在實際操作過程中，工程師在拓張這個小模塊的時候，不太容易會去考慮橫向依賴的問題，因為當(dāng)時這些模塊都在Common里面，直接進(jìn)行互相依賴是非常符合直覺的，而且也不算是不遵守規(guī)范。然而要注意的是，這才是Commom代碼混亂的罪魁禍?zhǔn)?，Common文件夾縱容了不精心管理依賴的做法。當(dāng)Common里面的模塊依賴關(guān)系變得復(fù)雜，再想要移出來單獨成立一個模塊，就不是當(dāng)初設(shè)置Common時想的等規(guī)模大了再移除也不遲那么簡單了。 另外，Common有的時候也不僅僅是一個文件夾。 在使用Cocoapods來管理項目庫的時候，Common往往就是一個pod。這個pod里面會有A/B/C/D/E這些函數(shù)集或小模塊。如果要新開一個app或者Demo，勢必會使用到Common這個pod，這么做，往往會把不需要包含的代碼也包含進(jìn)去，我對項目有高度潔癖，這種情況會讓我覺得非常不舒服。 舉個例子：早年安居客的app還不是集齊所有新房、二手房、租房業(yè)務(wù)的。當(dāng)你剛開始寫新房這個app的時候，創(chuàng)建了一個Common這個pod，這里面包含了一些對于新房來說比較Common的代碼，也包含了對于這個app來說比較Common的代碼。過了半年或者一年，你要開始二手房這個app，我覺得大多數(shù)人都會選擇讓二手房也包含這個Common，于是這個Common很有可能自己走上另一條發(fā)展的道路。等到了租房這個業(yè)務(wù)要開app的時候，Common已經(jīng)非常之龐大，相信這時候的你也不會去想整理Common的事情了，先把租房搞定，于是Common最終就變成了一坨屎。 就對于上面的例子來說，還有一個要考慮的是，分出來的三個業(yè)務(wù)很有可能會有三個Common，假設(shè)三個Common里面都有公共的功能，交給了三個團(tuán)隊去打理，如果遇到某個子模塊需要升級，那么三個Common里面的這個子模塊都要去同步升級，這是個很不效率的事情。另外，很有可能三個Common到最后發(fā)展成彼此不兼容，但是代碼相似度非常之高，這個在架構(gòu)上，是屬于分類條理不清。 就在去年年中的時候，安居客決定將三個業(yè)務(wù)歸并到同一個App。好了，如果你是架構(gòu)師，面對這三個Common，你打算怎么辦？要想最快出成果，那就只好忍受代碼冗余，趕緊先把架子搭起來再說，否則你面對的就是剪不斷理還亂的Common。此時Common就已經(jīng)很無奈地變成一坨屎了。這樣的Common，你自己說不定也搞不清楚它里面到底都有些什么了，交給任何一個人去打理，他都不敢做徹底的整理的。 還有就是，Common本身就是一個粒度非常大的模塊。在阿里這樣大規(guī)模的團(tuán)隊中，即便新開一個業(yè)務(wù)，都需要在整個app的環(huán)境下開發(fā)，為什么？因為模塊拆分粒度不夠，要想開一個新業(yè)務(wù)，必須把其他業(yè)務(wù)的代碼以及依賴全部拉下來，然后再開新入口，你的新業(yè)務(wù)才能進(jìn)行正常的代碼編寫和調(diào)試。然而你的新業(yè)務(wù)其實只依賴首頁入口、網(wǎng)絡(luò)庫等這幾個小模塊，不需要依賴其他那么多的跟你沒關(guān)系的業(yè)務(wù)?，F(xiàn)在每次打開天貓的項目，我都要等個兩三分鐘，這非常之蛋疼。 但是大家真的不知道這個原因嗎？知道了這個原因，為什么沒人去把這些粒度不夠細(xì)的模塊整理好？在我看來，這件事沒人敢做。原因有以下幾點：
花這么大的成本只是為了減少開啟項目時候等待IDE打開時的那幾分鐘時間？我想如果我是你leader，我也應(yīng)該不會批準(zhǔn)你做這樣的事情的。所以，與其到了后面吃這個苦頭，不如一開始做架構(gòu)的時候就不要設(shè)置Common，到后面就能省力很多。架構(gòu)師的工作為什么是功在當(dāng)代利在千秋，架構(gòu)師的素質(zhì)為什么對團(tuán)隊這么重要？我覺得這里就是一個最好的體現(xiàn)。 簡而言之，不建議開Common的原因如下：
那么，不設(shè)Common會帶來哪些好處？
Common的好處只有一個，就是前期特別省事兒。然而它的壞處比好處要多太多。不設(shè)置Common，再小的模塊再小的代碼也單獨拎出來，最多就是Podfile里面要多寫幾行，多寫幾行最多只花費幾分鐘。但若要消除Common所帶來的罪孽，不是這幾分鐘就能搞定的事情。既然不用Common的好處這么多，那何樂而不為呢？ 假設(shè)將來你的項目中有一個類是用來做Location的，哪怕只有兩個文件，也給他開一個模塊就叫Location。如果你的項目中有一個類是用來做ImageProcess的，那也開一個模塊就叫ImageProcess。不要都放到Common里面去，將來你再開新的項目或者新的業(yè)務(wù)，用Location就寫依賴Location，用ImageProcess就寫依賴ImageProcess，不要再依賴Common了，這樣你的項目也好管理，管理Common的那個人日子過得也輕松（這個人其實都可以不需要了，把他的工資加到你頭上不是更好？:D），將來要升級，顧慮也少。 結(jié)束 本篇的內(nèi)容就到這里，希望能對大家有所幫助。干貨會在后續(xù)的系列文章里面撲面而來的！ |
|
|
