用 Swift 架構(gòu) iOS 應(yīng)用的正確姿勢！2017-06-28 12:44程序設(shè)計/iOS　　The Right Way to Architect iOS App with Swift

　　關(guān)于 iOS 架構(gòu)的文章感覺已經(jīng)泛濫了，前一陣正好 Android 官方推了一套 App Architecture，于是就在想，對于 iOS 來說，怎樣的架構(gòu)才是最適合的。帶著這個問題，我開始了探索。

　　Why Architecture Matters？

　　這是第一個也是最重要的問題，為什么會出現(xiàn)各種 Architecture Pattern？真的那么重要么？

　　我們來想一下，無論是做一個 App 還是搭一套后臺系統(tǒng)，如果是一次性的，今天用完明天就可以扔掉，那么怎么快怎么來，代碼重復(fù)、代碼邏輯、代碼格式統(tǒng)統(tǒng)不重要。

　　這種場景比較適合黑客馬拉松，而真實情況往往是我們的代碼需要上線，要對用戶負責，而一套好的架構(gòu)會讓這些事情變得更加容易。

　　好的架構(gòu)簡潔且整潔

　　說到架構(gòu)，往往會想到建筑，軟件架構(gòu)跟建筑不同的點是軟件架構(gòu)會隨著時間的推移進行演進，而實體建筑則沒這個特性。拋開時間維度，這二者還是有一定的相似性的。

　　好的架構(gòu)容易催生好的代碼，就像住在干凈整潔的房子里，會下意識地讓其中的家具、電器、擺飾等也井井有條。

　　好的架構(gòu)讓代碼更加容易維護

　　不容易維護的代碼往往有這么幾個特點：

　　抽象程度低

　　職責不明確

　　喜歡走捷徑

　　好的架構(gòu)能對 2 和 3 有一定的作用，對于第 1 點還是要看程序員的能力和經(jīng)驗。

　　抽象程度低

　　這樣的代碼往往是命令式編程產(chǎn)生的，也就是像 CPU 那樣的思考方式，把產(chǎn)品經(jīng)理的需求直觀地翻譯成代碼，而不對其中的共性、本質(zhì)進行抽離和抽象，時間一長就容易看不懂其中的邏輯，需求一變就要改核心代碼。

　　比如下面這段代碼，不知道具體要完成什么任務(wù)。

　　職責不明確

　　這也是產(chǎn)生「一大坨代碼」的原因之一，就像 MVC 模式里，沒有說明用戶的操作應(yīng)該在哪里處理，業(yè)務(wù)邏輯放在什么地方，這樣就容易走捷徑，怎么方便怎么來，而越是方便到后來就越容易出問題。