iOS應用架構談開篇

[有些觀點比較贊同；

每天都在學習，新技術新思想上手速度快，理解速度快

做不到這點，你就是碼農

業務出身，或者至少非常熟悉公司所處行業或者本公司的業務

做不到這點，你就是運維

熟悉軟體工程的各種規範，踩過無數坑。不會為了完成需求不擇手段，不推崇quick & dirty

做不到這點，你比較適合去競爭對手那兒當工程師

及時承認錯誤，不要覺得承認錯誤會有損你架構師的身份

做不到這點，公關行業比較適合你

不為了炫技而炫技

做不到這點，你就是高中程式設計愛好者

精益求精

做不到這點，（我想了好久，但我還是不知道你適合去幹什麼。）

**整齊，分類明確，沒有common，沒有core

不用文件，或很少文件，就能讓業務方上手

思路和方法要統一，盡量不要多元

沒有橫向依賴，萬不得已不出現跨層訪問

對業務方該限制的地方有限制，該靈活的地方要給業務方創造靈活實現的條件

易測試，易拓展

保持一定量的超前性

介面少，介面引數少

高效能

以上是我判斷乙個架構是不是好架構的標準，這是根據重要性來排列的。客戶端架構跟服務端架構要考慮的問題和側重點是有一些區別的。下面我會針對每一點詳細講解一下

簡而言之，不建議開common的原因如下：

common不僅僅是乙個資料夾，它也會是乙個pod。不管是什麼，在common裡面很容易形成錯綜複雜的小模組依賴，在模組成長過程中，會縱容工程師不注意依賴的管理，乃至於將來如果要將模組拆分出去，會非常的困難。

common本身與細粒度模組設計的思想背道而馳，屬於一種不合適的偷懶手段，在將來業務拓張會成為阻礙。

一旦設定了common，就等於給地獄之門開啟了乙個小縫，每次業務迭代都會有一些不太好分類的東西放入common，這就給維護common的人帶來了非常大的工作量，而且這些工作量全都是體力活，非常容易出錯。

那麼，不設common會帶來哪些好處？

強迫工程師在業務拓張的時候將依賴管理的事情考慮進去，讓模組在一開始發展的時候就有自己的土壤，成長空間和靈活度非常大。

減少各業務模組或者demo的體積，不需要的模組不會由於common的存在而包含在內。

可維護性大大提高，模組公升級之後要做的同步工作非常輕鬆，解放了那個苦逼的common維護者，更多的時間可以用在更實質的開發工作上。

符合細粒度模組劃分的架構思想。

iOS應用架構談 開篇