提几个问题 大家一起来讨论下
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）那种方式进行下去，毕竟重构的成本太高，尤其是软件已经有大量用户基础。
我觉得这个问题，我比较有发言权
PS：有一件事说在前面，因为重要。 就是要抽时间回顾自己写的代码。
底下写了很长，发现没有回答楼主问题：
（1）说的对
（2）老项目要看情况，改代码也可以构架一下的。多人协作的话，一定要分工明确，要有写SDK的态度
（3）说的很对，以前也是这样
（4）即使是小公司，两三个人，甚至一个人，也最好按（3）进行开发，否则可能一两年三四年，发现自己的代码库，只有一堆工程，而没有提取的精华
看看这个狗逼的项目你就知道了Sun7400/YYKit 这狗逼做iOS才一年多
我的第一份工作，是做地图导航SDK开发，后来也有在App Store上发布小型App，也外包接过新闻客户端、网购平台这样的大项目，其实都是有共通之处的。关于项目的构架问题，我有如下建议：
使用
cocospods或其他的第三方代码工具，统一管理必要的第三方代码，就是好用，想着几年前加三方库各种链接和运行时错误，就觉得现在真幸福不要刻意去迎合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
祝你好运
好问题。先关注了。
怎样合算取决于项目的生命周期
如果项目短期都不会取消, 同时还要改来改去, 那.. 长痛不如短痛
重构未必要一个版本全部做完, 可以把旧代码一点点拆出来, 同时尽量写测试保证行为不变