ios - 关于体量大的APP，代码的如何架构依赖，才会对于后期迭代修改带来方便？

Question

提几个问题 大家一起来讨论下
1.一款迭代开发2-3年以上的APP怎么样的项目架构才是比较好的呢？
（1）一般现在 小团队开发（1-3人） 新的app 一般都会使用 pod来进行依赖管理第三方库，当然也可以管理本地的库。
这样子 第三方库基本上不需要去太大的搭理，只需要管理好podfile就可以了。
代码里使用mvc也好 mvvm也罢，文件不管怎么分，基本上就2个工程，一个主app工程 一个pod管理的第三方库工程。
（2）但是如果老项目 依然是小团队开发的 历史遗留 可能就没有使用pod了，可能混乱一点的 就只有一个主工程了，第三方库直接下下来拖进去好了，更新么就把文件换掉即可。
但是可能依然只有1 ，2个开发，其实影响并不是很大。
但是如果老项目是5人以上的话，这个影响就可以发生了，这个时候 项目分工 迭代开发 可能就会发生很混乱了。那这种项目有啥好的解决办法呢。
（3）现在大公司 大项目 例如微信 网易新闻等 这种体量很大的app，大部分应该是多工程 多依赖 来进行管理的。抽出和业务依赖非常小的模块作为核心库，就算以后新开发的app也可以用到，这部分核心库 一般都是内部封装 提供,framwork静态库供其他team使用，而且各不同业务的team之间也是代码保密状态 只有api沟通。不同的业务就是不同的SDK，最后一个app就是 多个不同的库 组合在一起 加耦合性高的业务代码进行组合。（以上都是小人之见，个人还没有参与过 10人以上的开发）。

毕竟软件项目都是不断成长的 ，是否在软件体量达到一定量的时候 就需要进行（3）那种模式的重构，还是说 就照着（1）（2）那种方式进行下去，毕竟重构的成本太高，尤其是软件已经有大量用户基础。

Answer 1

我覺得這個問題，我比較有發言權

PS：有一件事說在前面，因為重要。 就是要抽空回顧自己寫的程式碼。

底下寫了很長，發現沒有回答樓主問題：
（1）說的對
（2）舊項目要看情況，改代碼也可以構架一下的。多人協作的話，一定要分工明確，要有寫SDK的態度
（3）說的很對，以前也是這樣
（4）即使是小公司，兩三個人，甚至一個人，也最好按（ 3）進行開發，否則可能一兩年三四年，發現自己的程式碼庫，只有一堆工程，而沒有提取的精華

看看這個狗逼的項目你就知道了Sun7400/YYKit 這狗逼做iOS才一年多

我的第一份工作，是做地圖導航SDK開發，後來也有在App Store上發布小型App，也外包接過新聞客戶端、網購平台這樣的大項目，其實都是有共通之處的。關於專案的架構問題，我有以下建議：

1. 使用cocospods或其他的第三方程式碼工具，統一管理必要的第三方程式碼，就是好用，想著幾年前加三方庫各種連結和運行時錯誤，就覺得現在真幸福cocospods或其他的第三方代码工具，统一管理必要的第三方代码，就是好用，想着几年前加三方库各种链接和运行时错误，就觉得现在真幸福

2. 不要刻意去迎合MVC或MVVC的理论，一切开发以低耦合为基本标准

3. 项目中间，复用率最低的是ViewController，所以要用Storyboard来完成页面布局，省去ViewController的UI代码，这样做的好处就是，UI改版的时候，不用大量修改VC代码

4. 复用率最高的是一些基础功能，例如URL编码、UIImage切割、MD5索引等等等等，这些功能单拿出来，因为耦合很低

5. 复用率次高的是一些核心算法，比如导航引擎的算路、抽稀等，其实现在做项目，需要自己去捣鼓的算法已经很少了，如果有，把它抽出来封装，不要随便写在VC里面

6. 自定义控件，不要偷懒不去继承封装，包括Cell，简单说就是不要再VC里面去构建控件

7. 如果你尝试过把VC中的TableViewDelegate方法都拿出来单独封装，那你有没有试过继承一个TableView，让他自己做自己的DataSource呢？

8. 网络、CoreData和Model，使用先进的第三方框架来进行封装，比如MagicalRecord

9. 不要刻意去迎合MVC或MVVC的理論，一切開發以低耦合為基本標準

專案中間，復用率最低的是ViewController，所以要用Storyboard來完成頁面佈局，省去ViewController的UI程式碼，這樣做的好處就是，UI改版的時候，不用大量修改VC代碼

• 復用率最高的是一些基本功能，例如URL編碼、UIImage切割、MD5索引等等等等，這些功能單拿出來，因為耦合很低

• 復用率次高的是一些核心演算法，例如導航引擎的算路、抽稀等，其實現在做項目，需要自己去搗鼓的算法已經很少了，如果有，把它抽出來封裝，不要隨便寫在VC裡面

• 自訂控件，不要偷懶不去繼承封裝，包括Cell，簡單說就是不要再VC裡面去構建控件

• 如果你試過把VC中的TableViewDelegate方法都拿出來單獨封裝，那你有沒有試過繼承一個TableView，讓他自己做自己的DataSource呢？

• 網路、CoreData和Model，使用先進的第三方框架來進行封裝，例如MagicalRecord，和一些自動捆綁json->model的框架

• 一個方法程式碼超過20行，考慮是否有必要拆分
  🎜 🎜最後附上我的項目一般的結構🎜 🎜 🎜🎜ViewController目錄，下面根據不用頁面分目錄🎜🎜 🎜🎜View目錄 自訂控制項與Cell🎜🎜 🎜🎜3rd 直接拉進專案的第三方程式碼🎜🎜 🎜🎜Func 功能代碼🎜🎜 🎜🎜CoreData model和資料庫控制器🎜🎜 🎜🎜API 網路介面🎜

分類一個最大的好處就是能迅速定位程式碼，並且及使專案很大，你也能清晰地捋清一項事務的運作流程。

最後如果你使用CoreData，推薦研究研究NSFetchedResultsController
這是我封裝的一個zsy78191/DEFetchRC

祝你好運

Answer 2

怎麼合算取決於專案的生命週期
如果專案短期都不會取消, 同時還要改來改去, 那.. 長痛不如短痛

重構未必要一個版本全部做完, 可以把舊程式碼一點點拆出來, 同時盡量寫測試保證行為不變

Answer 3

好問題。先關注了。