摘要：移動(dòng)精英開發(fā)社群的第期，也是圍繞架構(gòu)這個(gè)話題進(jìn)行討論。本次我們希望結(jié)合實(shí)際開發(fā)中遇到的問題，來聊聊移動(dòng)端的架構(gòu)設(shè)計(jì)。這樣的模式改進(jìn)一些，可能會(huì)更適合移動(dòng)端架構(gòu)。潘衛(wèi)杰之前我們公司移動(dòng)端的大項(xiàng)目就是插座式開發(fā)的，批量出各個(gè)行業(yè)的。

此前，58 同城的技術(shù)委員會(huì)執(zhí)行主席沈劍在 OneAPM 的技術(shù)公開課上分享過一個(gè)主題，「好的架構(gòu)不是設(shè)計(jì)出來的，而是演技出來的」。因?yàn)閷?duì)很多創(chuàng)業(yè)公司而言，隨著業(yè)務(wù)的發(fā)展，網(wǎng)站流量或者移動(dòng)端用戶都會(huì)經(jīng)歷不同的階段。前期的時(shí)候，很難去設(shè)計(jì)一個(gè)百萬或者千萬級(jí)并發(fā)的架構(gòu)，所以后期往往不斷對(duì)架構(gòu)進(jìn)行更新迭代。

當(dāng)然，在這里也推薦一篇文章《移動(dòng)開發(fā)中的痛點(diǎn)》，本文是 infoQ 舉辦線下聚會(huì)的一次討論整理，當(dāng)時(shí)參與的討論者包括唐巧、郭亮、郭虹宇、鄧宇光、代碼家等國內(nèi)知名移動(dòng)開發(fā)者。其中就談及了 MVC 架構(gòu)的痛點(diǎn)，以及 React Native 所代表的 Web 開發(fā) Native App 技術(shù)，相信會(huì)對(duì)大家有所啟發(fā)。移動(dòng)精英開發(fā)社群的第8期，也是圍繞「架構(gòu)」這個(gè)話題進(jìn)行討論。本文系滴滴出行的劉佳達(dá)整理。

以下為討論內(nèi)容整理：

主持人韓兵：「架構(gòu)」對(duì)開發(fā)者而言就是「高大上」，當(dāng)然也不是每位 coder 都能搞定。對(duì)很多菜鳥而言就更陌生了，基本只能停留在理論層次。實(shí)踐才能出真知，一個(gè)好的架構(gòu)也是這樣產(chǎn)生的。本次我們希望結(jié)合實(shí)際開發(fā)中遇到的問題，來聊聊移動(dòng)端的架構(gòu)設(shè)計(jì)。

李文杰：我們的項(xiàng)目劃分成了：數(shù)據(jù)層、UI 層、邏輯層。

上海-李博：我們使用的是 MVVM（Model-View-ViewModel），然后使用了一些 React Native。

韓兵：MVC 這樣的模式可以代替咱們移動(dòng)端架構(gòu)嗎？

攻城獅：MVC、MVVM 只是一種設(shè)計(jì)模式而已。

Wallace：個(gè)人認(rèn)為， MVC 這種經(jīng)典結(jié)構(gòu)已經(jīng)滿足不了現(xiàn)在的需求了。

Rory：MVC 這樣的模式改進(jìn)一些，可能會(huì)更適合移動(dòng)端架構(gòu)。從業(yè)務(wù)邏輯的角度看，架構(gòu)應(yīng)該服從業(yè)務(wù)邏輯。

王威特-明道-ios：基于團(tuán)隊(duì)、服務(wù)于團(tuán)隊(duì)的代碼基礎(chǔ)規(guī)范包含開發(fā)模式，代碼規(guī)范等等。

Draven-ios：我認(rèn)為，MVVM + React Native 能讓開發(fā)變得輕松很多。

李文杰-上海數(shù)云-ios：特別希望有一套成熟的架構(gòu)，UI 和邏輯都寫好了。只要寫寫數(shù)據(jù)就可以用了。我針對(duì)的是超快速的簡(jiǎn)單需求 APP 開發(fā)，就像很多建站技術(shù)一樣，「拖一拖」就可以完成。

攻城獅：功能模塊化也是架構(gòu)中很重要的一環(huán)。

小龍：萬變不離其宗，天下武功出一家！ 移動(dòng)端各路設(shè)計(jì)不也是圍繞著 MVC 控制顯示數(shù)據(jù)，然后再做各種拆分嗎？

露露：模塊與模塊之間，應(yīng)該能快速拆分然后移植到新的項(xiàng)目中吧？

蜂鳥：用 React 基于響應(yīng)式函數(shù)編程是可以簡(jiǎn)化實(shí)現(xiàn)過程，省很多代碼。

劉玉嬌-小鄰小里-ios：?jiǎn)栂麓蠹揖W(wǎng)絡(luò)層搭建用的是 delegate 還是 block ？我們后來用的，發(fā)現(xiàn)好像 delegate 會(huì)好一點(diǎn)。

Draven-ios：block 比較靈活。

王宇-陸金所-ios：但是 block 寫的太隨意了。

Draven-ios：delegate 看起來比較規(guī)范。

小龍：block 是方便，但別忘了它是一個(gè)結(jié)構(gòu)體。

蜂鳥：昨天碰到一個(gè)問題，就是一個(gè) App 有100多個(gè)人共同開發(fā)，怎么設(shè)計(jì)架構(gòu)？才能讓100個(gè)人協(xié)同開發(fā)不出問題？

A-困惑：一般用 block。

Icocos：之前有人討論過，說用 MVP 比較好。

小龍：如果東西多了很重的，delegate 傳的時(shí)候只是一個(gè)指針。

進(jìn)擊的小比克：一部分做網(wǎng)絡(luò)層，一部分做業(yè)務(wù)邏輯，一部分做 UI。

王威特-明道-ios：delegate 書寫規(guī)范，也可以避免循環(huán)引用的問題。block 書寫流暢，但是會(huì)把網(wǎng)絡(luò)的代碼分散在各處，最終維護(hù)不一定好。建議在網(wǎng)絡(luò)業(yè)務(wù)種的結(jié)構(gòu)內(nèi)用 delegate，反之block更方便。

露露：如果幾個(gè)實(shí)例用一個(gè) delegate，需要判斷。

上海-李博：我覺得，進(jìn)行工程性的管理，還是比較好。各做各的業(yè)務(wù)，淘寶就是采用這種模式。相當(dāng)于每個(gè)業(yè)務(wù)維護(hù)一個(gè)工程。

潘衛(wèi)杰：可以使用插座式的模塊開發(fā)。分成多個(gè)小 Team ，負(fù)責(zé)相對(duì)獨(dú)立的業(yè)務(wù)功能開發(fā)，每個(gè) Team 配一個(gè)測(cè)試，通過了就提交，隨時(shí)可以打包出成品。

韓兵：之前也有人說了，架構(gòu)是不僅僅是為了方便業(yè)務(wù)，還有一個(gè)是為了我們 coder 快速開發(fā)。那架構(gòu)解決了我們項(xiàng)目開發(fā)中的什么問題？

露露：現(xiàn)在 block 用的很多，但是怎么才算使用的好呢？

小龍：delegate 是指針，block 是結(jié)構(gòu)體，一個(gè)傳遞的時(shí)候輕，但寫著麻煩，一個(gè)寫著方便傳遞的時(shí)候比較重。

潘衛(wèi)杰：之前我們公司移動(dòng)端的大項(xiàng)目就是「插座式」開發(fā)的，批量出各個(gè)行業(yè)的 App。

Rory：移動(dòng)架構(gòu)設(shè)計(jì)和選型根據(jù)我的經(jīng)驗(yàn)應(yīng)該遵守以下幾個(gè)原則吧：

優(yōu)先保證業(yè)務(wù)邏輯；

架構(gòu)設(shè)計(jì)遵循簡(jiǎn)潔的原則；

架構(gòu)的學(xué)習(xí)成本不要太高，需要符合當(dāng)前技術(shù)團(tuán)隊(duì)內(nèi)開發(fā)人員的能力范圍；

架構(gòu)是在開發(fā)過程中不斷擴(kuò)充和維護(hù)的，代碼重構(gòu)也是架構(gòu)的核心之一。

劉玉嬌：還有個(gè)問題，大家 VC 的分層是 base 然后下邊分為 baselist 和 baseentity 然后往下繼承嗎？

上海-李博：我感覺上面說的繼承這樣下去會(huì)越來越痛苦

潘衛(wèi)杰：前年的時(shí)候，行業(yè)內(nèi)有一個(gè)說法：各個(gè)行業(yè)扁平化，去中心化，很多行業(yè)老板也都想有自己的電子商務(wù)平臺(tái)。我們之前就給他們解決這個(gè)問題，但是我們又不能每家都出一個(gè)，就用這種方式出一個(gè)很多功能的，各家用的時(shí)候在后臺(tái)自定義組合。

小龍：高內(nèi)聚低耦合！

Noark9：以前公司做一個(gè) Windows 上應(yīng)用的覺得思路可以借鑒：我們有一個(gè)比較大的，我們稱為 shell（殼程序），然后，殼程序提供了接口請(qǐng)求的框架，用戶信息的接口，發(fā)送通知，以及一些公共的功能。然后，每個(gè)小功能，都作為一個(gè)動(dòng)態(tài)庫接入，殼程序負(fù)責(zé)加載下載下來的動(dòng)態(tài)庫，然后打開到界面上。

王宇-陸金所-ios：具體怎么和業(yè)務(wù)模塊拆分方法呢？

韓兵：服務(wù)端都是重架構(gòu)，一般移動(dòng)端都偏輕架構(gòu)。

王威特：是，繼承的耦合性太重。用組合的方式更好，前幾天的一篇文章就非常推薦閱讀。

http://blog.yongfengzhang.com/cn/blog/write-code-that-is-easy-to-delete-not-easy-to/

Rory：理論上，架構(gòu)不一定要多復(fù)雜。但是至少簡(jiǎn)明的可以區(qū)分組件、組件的邏輯、業(yè)務(wù)邏輯、數(shù)據(jù)層。讓組件的邏輯和業(yè)務(wù)邏輯分離，減少代碼耦合；方法的適量重載和重寫；在項(xiàng)目的維護(hù)期，抽離項(xiàng)目特有的組件。

蜂鳥：具體到寫代碼，就是多用接口，定義個(gè)協(xié)議來實(shí)現(xiàn)后使用它。

小龍：面向協(xié)議就是看接口定義的怎么樣了?？梢园迅餍袠I(yè)一些特性歸類為某一類屬性，統(tǒng)一處理，最后用的時(shí)候換個(gè)皮，換套文案就可以。

蜂鳥：API 接口定義的好，說明模塊分離，邊界定義的很清楚。

小龍：面向協(xié)議的變成是不是給 ViewController 暴露的都是 id<某個(gè)協(xié)議> ？這種形式的，而不需要 import 具體的類？求解答。

你該休息了：Android 架構(gòu)中熱部署大家常采用的多嗎 ？

李哲-京東：我重寫的時(shí)候，就遵循的就是各個(gè)模塊的拆分。將業(yè)務(wù)，功能，包括很小的通知名，顏色，緩存路徑都搞成了宏定義。將網(wǎng)絡(luò)，數(shù)據(jù)，業(yè)務(wù)，功能都剝離了出來。

王威特：宏定義寫起來有些難堪，用 const string 不是更好嗎？

韓兵：可以推薦一些架構(gòu)設(shè)計(jì)比較好的來源代碼

阿塵：個(gè)人感覺，要深入移動(dòng)架構(gòu)，必須了解企業(yè)應(yīng)用架構(gòu)。開源的完整 App 應(yīng)該比較少。為什么要有架構(gòu)？根本原因還是在于復(fù)雜性。頭一次看到就五體投地，之前用 NimbusKit 搭架構(gòu)，現(xiàn)在打算轉(zhuǎn)向 YYKit 。簡(jiǎn)單的 App 是不需要架構(gòu)的。

李哲：將一些業(yè)務(wù)的解決方法，使用模型思想去解決，尤其是那個(gè)微博列表的設(shè)計(jì)。要寫易刪除，而不易擴(kuò)展的代碼。

阿塵：個(gè)人感覺，合理的分層設(shè)計(jì)很關(guān)鍵。

哈哈：比如微信 SDK，集成了登錄、分享、支付三個(gè)大的功能，不支持多帶帶拆分使用，如果之前已經(jīng)使用了友盟、shareSDK 等，只想接入微信支付功能，就會(huì)出現(xiàn)沖突問題。

阿塵：架構(gòu)的構(gòu)建是一個(gè)不斷權(quán)衡的過程。

有一個(gè)道理：架構(gòu)的構(gòu)建是一個(gè)不斷權(quán)衡的過程？這個(gè)有點(diǎn)不同意。

蜂鳥：我覺得架構(gòu)之所以需要，就是要保持一個(gè)基本的穩(wěn)定架構(gòu)，別變來變?nèi)サ?。再變也是?xì)節(jié)和模塊功能的補(bǔ)充，跳不出已經(jīng)設(shè)定好的架構(gòu)。

韓兵：好的東西都不是不斷改，不斷優(yōu)化的。

小龍：響應(yīng)式編程思想：不需要考慮調(diào)用順序，只需要知道考慮結(jié)果，類似于蝴蝶效應(yīng)，產(chǎn)生一個(gè)事件，會(huì)影響很多東西，這些事件像流一樣的傳播出去，然后影響結(jié)果，借用面向?qū)ο蟮囊痪湓?，萬物皆是流。

而函數(shù)式編程思想是把操作盡量寫成一系列嵌套的函數(shù)或者方法調(diào)用。函數(shù)式編程特點(diǎn)：每個(gè)方法必須有返回值（本身對(duì)象），把函數(shù)或者 Block 當(dāng)做參數(shù)，block 參數(shù)（需要操作的值）block 返回值（操作結(jié)果）。

代表：ReactiveCocoa。

李哲-京東：而一個(gè)好的架構(gòu)也總是在業(yè)務(wù)不斷變化中慢慢變好的。

小龍：鏈?zhǔn)骄幊趟枷耄菏菍⒍鄠€(gè)操作（多行代碼）通過點(diǎn)號(hào)(.)鏈接在一起成為一句代碼,使代碼可讀性好。a(1).b(2).c(3)

鏈?zhǔn)骄幊烫攸c(diǎn)：方法的返回值是 block,block 必須有返回值（本身對(duì)象），block 參數(shù)（需要操作的值）

代表：masonry 框架。

蜂鳥：如果架構(gòu)總是變來變?nèi)?，恰恰證明了架構(gòu)設(shè)計(jì)的不合理。

攻城獅：現(xiàn)在好多大公司有個(gè)技術(shù)平臺(tái)部，把一些功能抽象出來模塊化，這樣業(yè)務(wù)線開發(fā)就簡(jiǎn)單很多，效率也高了。

阿塵：架構(gòu)是一組決策的組合，做每個(gè)決策的過程都是一次取舍和權(quán)衡，這樣理解嗎？我覺得，實(shí)踐出真知，從0開始打造一個(gè)復(fù)雜 App 的過程，會(huì)讓你受益匪淺。

王威特：這回到主持人說的，架構(gòu)是經(jīng)驗(yàn)積累出來的，慢慢來。即使做了一個(gè)壞架構(gòu)，以后和別人的對(duì)比下就收獲頗豐了。

攻城獅：架構(gòu)不是一下就有的，走過才知道捷徑。

蜂鳥：同意你說的決策的取舍平衡，我的看法是這種決策取舍越少越好。好的架構(gòu)應(yīng)該能有空間適應(yīng)這種業(yè)務(wù)的變化，預(yù)見到也許會(huì)有的改動(dòng)，有點(diǎn)理想化了。

王威特：一個(gè)長(zhǎng)期迭代的 App 做的就是架構(gòu)和業(yè)務(wù)，架構(gòu)能力也是慢慢磨出來的。如果在外包公司工作，更要做好架構(gòu)，才能快速開發(fā)。

攻城獅：有些公司 iOS 頁面跳轉(zhuǎn)是統(tǒng)一的一個(gè)管理類來管理的，在座各位有這么做的嗎？

進(jìn)擊的小比克：現(xiàn)在的項(xiàng)目既按功能模塊分，又分業(yè)務(wù)邏輯、網(wǎng)絡(luò)層、數(shù)據(jù)層，分得有點(diǎn)亂啊！和網(wǎng)絡(luò)服務(wù)器框架一樣。

高山：比如一個(gè)頁面，需要 abcd 四個(gè)頁面才能過來，現(xiàn)在一個(gè) url ，很多前置條件都沒有，可能導(dǎo)致錯(cuò)誤。這就對(duì)架構(gòu)解耦提出更高的要求。

王威特：最早 ABRouter ，你給 viewController 寫個(gè) category 就行了。這里說的是iOS，用 router 實(shí)現(xiàn)跳轉(zhuǎn)，一個(gè)極大的極大的便利就是以后你的 App 需要實(shí)現(xiàn)從 safari 瀏覽器打開 App ，發(fā)現(xiàn)你都搞定了。

韓兵：好像咱們討論組做服務(wù)端的人不多。什么是服務(wù)端架構(gòu)？服務(wù)端涉及的東西太多。只有親自設(shè)計(jì)過和處理過數(shù)量級(jí)比較大的系統(tǒng)，才可能會(huì)對(duì)架構(gòu)有所體悟。要不然很可能是「紙上談兵」。

Wallace：其實(shí)好的架構(gòu)，無非是能在你現(xiàn)有的情況下，能解決實(shí)際中存在的問題。有些很牛逼的架構(gòu)不一定適用于現(xiàn)在的具體場(chǎng)景。

韓兵：本身架構(gòu)包含的知識(shí)就很多，不僅僅一門編程語言。

攻城獅：Java 比較成熟，但是提供的架構(gòu)還有一些并不是很成熟。

檸檬：從頭看了下，都是偏于理論，對(duì)于架構(gòu)還是沒什么印象，比如說 MVC，這也是最基本的。但是如何做到架構(gòu)師級(jí)別？求指教。

檸檬：最近在整理一些知識(shí)，個(gè)人感覺，想能為架構(gòu)師，就是把基本的東西包「打包」在一個(gè)項(xiàng)目中。

Wallace：其實(shí)寫的時(shí)間長(zhǎng)了，很自然的就能時(shí)刻考慮到「高內(nèi)聚低耦合」的思維了。尤其是，寫完一個(gè)模塊后也可以錘煉自己。

韓兵：設(shè)計(jì)一個(gè) App，首先應(yīng)該考慮的就是它的架構(gòu)。先把結(jié)構(gòu)搭建起來，網(wǎng)絡(luò)層封裝好，第三方控件封裝好，然后最快速度支撐起業(yè)務(wù)層。其實(shí)在實(shí)際開發(fā)中，沒有那么多時(shí)間成本，還是需要優(yōu)化一些東西。

丁建龍：模塊化，最少的暴露參數(shù)和接口。

檸檬：目前所面臨的代碼質(zhì)量問題，絕大部分不是技術(shù)問題，不是 coding 能力問題，是節(jié)奏把控，是質(zhì)量觀念的問題，如何平衡 scope 、quality、schedule，這不是自下而上的變革，是自上而下的思想改變，每一個(gè)技術(shù) leader 都需要去權(quán)衡把控。

一切質(zhì)量問題，本質(zhì)上就是技術(shù) leader 的問題，很多人可能會(huì)說，業(yè)務(wù)需求太多，工作量太大，跑得太快，這些都是事實(shí)，事實(shí)的背后是，我們技術(shù)有沒有真正去理解業(yè)務(wù)，理解產(chǎn)品的思路和想法，理解業(yè)務(wù)的核心訴求和難點(diǎn)，大家一定可以平衡好這三方面的關(guān)系。

韓兵：大家的項(xiàng)目都是怎么搭建起來的？

檸檬：我們是第一版肯定是快速出原形，看用戶的功能，兩周一個(gè)迭代。成型后重構(gòu)。

Rory：初期：簡(jiǎn)易架構(gòu)，實(shí)現(xiàn)基礎(chǔ)功能，組件；開發(fā)過程中：迭代豐富組件，抽離業(yè)務(wù)，形成模塊化。像初期選型，我可以用諾遠(yuǎn)目前1.0->1.1的版本發(fā)展歷程舉個(gè)例子。后期維護(hù)擴(kuò)容，可以用365日歷的 Android 客戶端舉個(gè)例子。

韓兵：這個(gè)只有實(shí)踐過，才可能會(huì)有一些感悟。說說大家 App 從無到有的構(gòu)建過程。從這個(gè)過程中理解架構(gòu)的形成和運(yùn)作。個(gè)人覺得從這點(diǎn)入手，會(huì)容易理解一些。

檸檬：架構(gòu)看功力，架構(gòu)師的路很長(zhǎng)，不斷的被指責(zé)，改進(jìn)的過程，這是漫長(zhǎng)的過程。我現(xiàn)在的想法是把幾乎所有項(xiàng)目都用到的東西，整理在一個(gè)項(xiàng)目下，以后獨(dú)立開發(fā)可以直接運(yùn)用。還可以把整個(gè)項(xiàng)目底層做一個(gè)基類。

Rory：目前互聯(lián)網(wǎng)行業(yè)主要還是敏捷開發(fā)，所以初期選型的時(shí)候，其實(shí)架構(gòu)細(xì)分顯得不是很重要，倒是架構(gòu)上為后期模塊化，可擴(kuò)展性的方面考慮更多。比如，小諾理財(cái) Android 客戶端，初期架構(gòu)只做了網(wǎng)絡(luò)層，數(shù)據(jù)解析，activity 基類封裝，圖片緩存，和一些常用的 UI 組件。

露露：我覺得你可以整合，但是如果用了某一個(gè)功能，能快速拆分。

Wallace：我曾經(jīng)最開始工作的時(shí)候，以為把見過的東西都存下來，到時(shí)候用上，但其實(shí)都沒用上。

Rory：整體上業(yè)務(wù)結(jié)構(gòu)初期都是在 Activity 中處理的，沒有做業(yè)務(wù)邏輯的抽離。從1.0-1.1的過程中，這邊的 Android 技術(shù)團(tuán)隊(duì)進(jìn)行了一些重構(gòu)和業(yè)務(wù)抽離，構(gòu)建基礎(chǔ)。形成目前定制的 UI組件庫（目前 UI 組件的邏輯仍然未進(jìn)行細(xì)致抽離）、業(yè)務(wù)邏輯 control 單元（目前是依據(jù)業(yè)務(wù)模塊的不同，抽離不同模塊的 control。）這么做，主要的目的是為了后續(xù)新加入的技術(shù)，可以快速熟悉項(xiàng)目，了解業(yè)務(wù)。

韓兵：如果這個(gè)項(xiàng)目越做越大，咱們就暫定理財(cái)項(xiàng)目，是不是要考慮底層框架對(duì)現(xiàn)有業(yè)務(wù)的支持？如果團(tuán)隊(duì)越來越大，是不是還要考慮對(duì)n多個(gè)團(tuán)隊(duì)的支持？

Rory：理財(cái)和支付一樣，對(duì)數(shù)據(jù)安全和通信安全比較重視。

阿塵：橫向業(yè)務(wù)模塊化，豎向低耦合，做到單向依賴。

Rory：曾經(jīng)參與過，365日歷 Android 客戶端的后期維護(hù)。當(dāng)時(shí)客戶端項(xiàng)目到了后期，模塊劃分會(huì)越來越多，項(xiàng)目會(huì)變得越來越臃腫。這時(shí)候在 java 層面和 Android framework 層的優(yōu)化其實(shí)更少。

多數(shù)組件這時(shí)候都已經(jīng)很成熟，這時(shí)候需要集成性能測(cè)試，針對(duì)某一點(diǎn)上進(jìn)行細(xì)節(jié)優(yōu)化。架構(gòu)上也是抽離出更多的庫，進(jìn)行細(xì)分支持。365日歷其實(shí)是典型的 MVC 向 MVP 的過渡。當(dāng)然，我離職的時(shí)候這個(gè)過渡還未完成?；旧想r形可以看到，UI 層和業(yè)務(wù)層已經(jīng)進(jìn)行深度劃分，通過 control 控制數(shù)據(jù)傳遞和通信。

MVP，個(gè)人經(jīng)驗(yàn)更適合移動(dòng)端，移動(dòng)端開發(fā)的主要難點(diǎn)是兩個(gè)，業(yè)務(wù)邏輯和界面效果。

韓兵：所以移動(dòng)端和服務(wù)端考慮的點(diǎn)也是不一樣的！

Rory：把 UI 和業(yè)務(wù)邏輯區(qū)分，這樣控制單元更有針對(duì)性，對(duì)原有業(yè)務(wù)或者UI的修改更有針對(duì)性，迭代過程中產(chǎn)生錯(cuò)誤理解和錯(cuò)誤邏輯導(dǎo)致 bug 的可能性也更小。

可能因?yàn)檫@樣抽離后，新技術(shù)的加入，理解項(xiàng)目需要更長(zhǎng)的時(shí)間。代碼閱讀性會(huì)隨著項(xiàng)目的臃腫變得越來越差。所以必要的抽離就是保證代碼的可讀性。

過渡重構(gòu)舉個(gè)很簡(jiǎn)單的例子，一個(gè) View 的 UI 邏輯非要強(qiáng)行適應(yīng)整個(gè)項(xiàng)目所有的 View，創(chuàng)造 n 個(gè)構(gòu)造，傳入多個(gè)控制參數(shù)。那么邏輯理解起來是不是很困難？最簡(jiǎn)單的判定標(biāo)準(zhǔn)，代碼的創(chuàng)造者如果隔一段時(shí)間都很難讀得懂自己寫的代碼，算不算一種過度？

簡(jiǎn)單的總結(jié)下，架構(gòu)應(yīng)該隨著項(xiàng)目發(fā)展不斷發(fā)展，一成不變的架構(gòu)是行不通的！

國內(nèi) ITOM 管理平臺(tái) OneAPM 致力于幫助企業(yè)用戶提供全棧式的性能管理以及 IT 運(yùn)維管理服務(wù)，通過一個(gè)探針就能夠完成日志分析、安全防護(hù)、APM 基礎(chǔ)組件監(jiān)控、集成報(bào)警以及大數(shù)據(jù)分析等功能。想閱讀更多優(yōu)秀文章，請(qǐng)?jiān)L問 OneAPM 官方技術(shù)博客
本文轉(zhuǎn)自 OneAPM 官方博客