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

この問題については私にも発言権があると思います

追記: 重要なことがあるので、最初に言っておきます。 時間をかけて、作成したコードを確認してください。

以下に長い記事を書きましたが、元の投稿者の質問に答えていないことがわかりました:
(1) その通りです
(2) 古いプロジェクトの状況次第です。コードを変更して構造化します。複数人で共同作業する場合は、明確な分業と SDK を書く姿勢が必要です
(3) おっしゃる通り、以前も同じでした
(4) 小さな会社でも 2 ～ 3 人(3) に従って開発するのが最善です。そうしないと、1 年、2 年、3 年、または 4 年でコードベースに本質が抽出されずに大量のプロジェクトしか残らない可能性があります

この素晴らしいプロジェクトを見れば、Sun7400/YYKit が iOS 上で 1 年以上稼働していることがわかります。

私の最初の仕事は地図ナビゲーション SDK の開発でした。その後、App Store で小規模なアプリをリリースしたり、ニュース クライアントやオンライン ショッピング プラットフォームなどの大規模なプロジェクトも委託しました。 。プロジェクトの構造に関して、次のような提案があります:

1. cocospods などのサードパーティ コード ツールを使用して、必要なサードパーティ コードを一元的に管理できます。サードパーティ ライブラリを追加する際のさまざまなリンクや実行時エラーを考慮して使用するのが簡単です。数年前に比べたら、今は本当に便利だと感じています。

2. MVC または MVVC の理論に意図的に対応しないでください。すべての開発は基本標準として 低耦合 に基づいて行う必要があります。

3. プロジェクトの中で最も再利用率が低いのは ViewController なので、Storyboard を使用してページレイアウトを完成させ、UI を作成する際に ViewController の UI コードが省略されるという利点があります。改訂されたため、VC を大幅に変更する必要はありません コード

4. 最も再利用可能な関数は、URL エンコード、UIImage のカット、MD5 インデックス作成などのいくつかの基本的な関数です。結合が非常に低いため、これらの関数が選ばれます

5. 次に再利用率が高いのは、ナビゲーション エンジンのパス計算や間引きなどの一部のコア アルゴリズムです。実際、現在プロジェクトを実行する場合、自分でいじる必要があるアルゴリズムはほとんどありません。あるので、出てきてカプセル化してください。VC に気軽に書かないでください

6. カスタム コントロールは、怠惰にせず、Cell を含むカプセル化を継承しないでください。簡単に言えば、VC でコントロールを構築しないでください。

7. VC のすべての TableViewDelegate メソッドを個別にカプセル化しようとした場合、TableView を継承して独自の DataSource を作成させてみましたか?

8. ネットワーク、CoreData、モデルは、MagicalRecord や自動的にバンドルされるいくつかの json->model フレームワーク

などの高度なサードパーティ フレームワークを使用してカプセル化されます。

9. メソッドコードが 20 行を超えているため、分割する必要があるか検討してください

最後に、私のプロジェクトの一般的な構造を示します

• ViewController ディレクトリ。以下はページごとにディレクトリに分かれています

• ディレクトリのカスタム コントロールとセルを表示

• 3 番目はプロジェクトのサードパーティ コードを直接プルします

• Func 関数コード

• CoreData モデルとデータベース コントローラー

• API ネットワークインターフェース

分類の最大のメリットの 1 つは、コードをすぐに見つけられることと、プロジェクトが大規模な場合でも、トランザクションの実行プロセスを明確にできることです。

最後に、CoreData を使用する場合は、調査することをお勧めします NSFetchedResultsController
これは私がパッケージ化した zsy78191/DEFetchRC です

幸運を祈ります

Answer 2

費用対効果はプロジェクトのライフサイクルによって異なります
プロジェクトが短期的にキャンセルされず、何度も変更する必要がある場合、...長期的な痛みはさらに深刻です短期的な痛み

リファクタリングは 1 つのバージョンで完了する必要はありません。古いコードを少しずつ分解して、動作が変わらないことを確認するテストを作成してみてください。

Answer 3

良い質問です。まず注意してください。