iOS 架構(gòu).png
一、好的架構(gòu)漫談
1.代碼整齊，分類明確，沒有common，沒有core
不要讓一個(gè)類或者一個(gè)模塊做兩種不同的事情，一方面不適合未來拓展，另一方面也造成分類困難
不要common，不要core：每個(gè)人認(rèn)為的common和core不一樣，同時(shí)軟件是有生命的，會(huì)不斷的迭代成長。如果有了common和core最后隨著業(yè)務(wù)和需求的不斷變更，一定會(huì)使得代碼變得一團(tuán)糟。
2.不要用文檔，或者很少用文檔就能讓業(yè)務(wù)方上手
- 開發(fā)時(shí)間緊
- 需求多
- 盡可能的使我們的API名字可讀性強(qiáng)
3.思路和方法要統(tǒng)一，盡量不要多元
- 方案要堅(jiān)定，不要搖擺
- 記錄方案的背景，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)
4.沒有橫向依賴，萬不得已不要出現(xiàn)跨層訪問
- 橫向依賴杜絕
- 跨層訪問有時(shí)候無法避免：網(wǎng)絡(luò)底層里面信號從2G變成了3G變成了4G，這是有可能需要跨層通知到View的。但這種情況不多，一旦出現(xiàn)就要想盡一切辦法在本層搞定或者交給上層或者下層搞定，盡量不要出現(xiàn)跨層的情況。跨層訪問同樣增加耦合度，當(dāng)某一層需要整體替換的時(shí)候，牽扯的面太廣。
5.對業(yè)務(wù)該限制的地方有限制，該靈活的地方要給業(yè)務(wù)方創(chuàng)造靈活實(shí)現(xiàn)的條件
- 限制：比如網(wǎng)絡(luò)請求數(shù)據(jù)回調(diào)使用統(tǒng)一方式比如Delegate或者Block
- 靈活：如果是設(shè)計(jì)一個(gè)ABTest相關(guān)的API的時(shí)候，我們又希望增加它的靈活性，使得業(yè)務(wù)不光可以通過Target-Action的模式實(shí)現(xiàn)ABTest，也可以通過Block的方式實(shí)現(xiàn)。盡可能滿足靈活性，減少業(yè)務(wù)方的使用成本
6.易測試，易拓展
- 易測試需要提高模塊化程度，盡可能減少依賴關(guān)系，便于mock測試。
- 高度模塊化容易拓展
7.保持一定量的超前性
- 產(chǎn)品需求：了解產(chǎn)品未來的發(fā)展方向
- 技術(shù)方案：組件化、動(dòng)態(tài)化、跨平臺
8.接口少，接口參數(shù)少
- 越少的接口越少的參數(shù)，就越能降低業(yè)務(wù)方的使用成本
- 滿足業(yè)務(wù)方的充要條件
9.高性能
- 重要但是不是第一要素
- 蘋果產(chǎn)品的性能已經(jīng)足夠好
- 不能因?yàn)閮?yōu)化性能影響穩(wěn)定性
10.架構(gòu)分層
- 按照業(yè)務(wù)分層：三層、四層。邏輯上有幾層就惡意分為幾次。每層具體做什么，叫什么沒有特定的規(guī)范。這主要針對模塊分類而言
- 按照數(shù)據(jù)流動(dòng)：MVC、MVVM
- 業(yè)務(wù)分層&數(shù)據(jù)流動(dòng)結(jié)合：
三層架構(gòu)：數(shù)據(jù)管理者、數(shù)據(jù)加工者、數(shù)據(jù)展示者
籠統(tǒng)來說，軟件只會(huì)有三層，每一層扮演一個(gè)角色。其他的第四、第五層一般都是這三層里面的其中之一分出來的，最后都能歸納為這三層中的某一層，所以三層描述比較普遍
