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

I think I have a better say on this issue

PS: There’s one thing I’ll mention up front because it’s important. Just take the time to review the code you wrote.

I wrote a long article below, but I found that I didn’t answer the original poster’s question:
(1) That’s right
(2) It depends on the situation of old projects. You can also structure it by changing the code. If multiple people collaborate, there must be a clear division of labor and an attitude towards writing an SDK
(3) You are right, it was the same before
(4) Even in a small company, with two or three people, or even one person, it is best to press ( 3) Carry out development, otherwise you may find that your code base only has a bunch of projects in one, two, three or four years without extracting the essence

Look at this awesome project and you will know Sun7400/YYKit. This awesome project has only been working on iOS for more than a year

My first job was to develop a map navigation SDK. Later, I also released small apps on the App Store, and also outsourced large projects such as news clients and online shopping platforms. In fact, they all have something in common. Regarding the structure of the project, I have the following suggestions:

1. Use cocospods or other third-party code tools to manage the necessary third-party code in a unified manner. It is easy to use. Thinking about the various links and runtime errors of adding third-party libraries a few years ago, I feel that now So happycocospods或其他的第三方代码工具，统一管理必要的第三方代码，就是好用，想着几年前加三方库各种链接和运行时错误，就觉得现在真幸福

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. Don’t deliberately cater to the theory of MVC or MVVC. All development should be based on low coupling as the basic standard

Among the projects, the one with the lowest reuse rate is ViewController, so Storyboard is used to complete the page layout and the UI code of ViewController is omitted. The advantage of this is that when the UI is revised, there is no need to make a lot of modifications. VC code

• The most reusable are some basic functions, such as URL encoding, UIImage cutting, MD5 indexing, etc. These functions are singled out because the coupling is very low

• The next highest reuse rate is some core algorithms, such as navigation engine path calculation, thinning, etc. In fact, when doing projects now, there are very few algorithms that need to be fiddled with by yourself. If there are, extract them and encapsulate them, don’t Just write it in VC

• When customizing controls, don’t be lazy and inherit the encapsulation, including Cell. Simply put, don’t build controls in VC

• If you have tried to take out all the TableViewDelegate methods in VC and encapsulate them separately, have you tried inheriting a TableView and letting it make its own DataSource?

• Network, CoreData and Model are encapsulated using advanced third-party frameworks, such as MagicalRecord, and some automatically bundled json->model frameworks

• If a method code exceeds 20 lines, consider whether it is necessary to split it
  🎜 🎜Finally, here is the general structure of my project🎜 🎜 🎜🎜ViewController directory, the following is divided into directories according to different pages🎜🎜 🎜🎜View Directory Custom Controls and Cell🎜🎜 🎜🎜3rd directly pulls in the third-party code of the project🎜🎜 🎜🎜Func function code🎜🎜 🎜🎜CoreData model and database controller🎜🎜 🎜🎜API network interface🎜

One of the biggest benefits of classification is that you can quickly locate the code, and even if the project is large, you can clearly clarify the running process of a transaction.

Finally, if you use CoreData, it is recommended to study itNSFetchedResultsController
This is the one I packaged zsy78191/DEFetchRC

Wish you good luck

Answer 2

The cost-effectiveness depends on the life cycle of the project
If the project will not be canceled in the short term and has to be changed again and again, then... the long-term pain is worse than the short-term pain

Refactoring does not have to be completed in one version. You can dismantle the old code bit by bit, and try to write tests to ensure that the behavior remains unchanged

Answer 3

Good question. Pay attention first.