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

Je pense avoir mon mot à dire dans ce numéro

PS : Il y a une chose que je mentionnerai d’emblée car elle est importante. Prenez simplement le temps de revoir le code que vous avez écrit.

J'ai écrit un long article ci-dessous, mais j'ai constaté que je n'avais pas répondu à la question de l'affiche originale :
(1) C'est vrai
(2) Cela dépend de la situation des anciens projets, et vous pouvez structurez-le également en changeant le code. Si plusieurs personnes collaborent, il doit y avoir une division claire du travail et une attitude envers l'écriture d'un SDK
(3) Vous avez raison, c'était pareil avant
(4) Même dans une petite entreprise, deux ou trois des personnes, ou même une seule personne, peuvent Il est préférable de développer selon (3), sinon vous risquez de constater que votre base de code n'a qu'un tas de projets en un, deux, trois ou quatre ans sans en extraire l'essence

Regardez ce projet génial et vous connaîtrez Sun7400/YYKit. Ce projet génial ne fonctionne sur iOS que depuis plus d'un an

.

Mon premier travail a été de développer un SDK de navigation cartographique. Plus tard, j'ai également publié de petites applications sur l'App Store, et j'ai également externalisé de grands projets tels que des clients d'actualités et des plateformes d'achat en ligne. . Concernant la structure du projet, j'ai les suggestions suivantes :

1. Utilisez cocospods ou d'autres outils de code tiers pour gérer le code tiers nécessaire de manière unifiée. Il est facile à utiliser de penser aux différents liens et erreurs d'exécution lors de l'ajout de bibliothèques tierces. il y a quelques années, je trouve que c'est vraiment utile maintenant.

Ne vous conformez pas délibérément à la théorie de MVC ou de MVVC. Tout développement doit être basé sur
2. comme norme de base

   低耦合.

Parmi les projets, celui avec le taux de réutilisation le plus bas est
3. , donc Storyboard est utilisé pour compléter la mise en page et le code de l'interface utilisateur de ViewController est omis. révisé, il n'est pas nécessaire de modifier beaucoup le VC Code

   ViewController

Les fonctions les plus réutilisables sont certaines fonctions de base, comme l'encodage d'URL, le découpage d'UIImage, l'indexation MD5, etc. Ces fonctions sont pointées du doigt car le couplage est très faible
Le deuxième taux de réutilisation le plus élevé concerne certains algorithmes de base, tels que le calcul du chemin du moteur de navigation, l'éclaircissement, etc. En fait, lorsque vous réalisez des projets maintenant, il y a très peu d'algorithmes qui doivent être manipulés par vous-même. il y en a, pompez-les. Sortez et encapsulez-le, ne l'écrivez pas avec désinvolture en VC
Contrôles personnalisés, ne soyez pas paresseux et héritez de l'encapsulation, y compris Cell. En termes simples, ne créez pas de contrôles dans VC

6. .

Si vous avez essayé d'encapsuler séparément toutes les méthodes TableViewDelegate dans VC, avez-vous essayé d'hériter d'une TableView et de la laisser créer sa propre source de données ?
Network, CoreData et Model sont encapsulés à l'aide de frameworks tiers avancés, tels que
8. , et certains frameworks json->model automatiquement regroupés

   MagicalRecord

Un code de méthode dépasse 20 lignes, réfléchissez s'il est nécessaire de le diviser
Enfin, voici la structure générale de mon projet

Répertoire ViewController, ce qui suit est divisé en répertoires selon différentes pages
Afficher les contrôles personnalisés et la cellule du répertoire
3ème récupérez directement le code tiers du projet
Code de fonction Func
Modèle CoreData et contrôleur de base de données
Interface réseau API

L'un des plus grands avantages de la classification est que vous pouvez localiser rapidement le code, et même si le projet est volumineux, vous pouvez clairement clarifier le processus en cours d'une transaction.

Enfin, si vous utilisez CoreData, il est recommandé de rechercher NSFetchedResultsController
Il s'agit de zsy78191/DEFetchRC que j'ai packagé

Je vous souhaite bonne chance

Answer 2

La rentabilité dépend du cycle de vie du projet
Si le projet n'est pas annulé à court terme et doit être modifié encore et encore, alors... la douleur à long terme est pire que la douleur à court terme

La refactorisation n'a pas besoin d'être effectuée en une seule version. Vous pouvez démonter l'ancien code petit à petit et écrire des tests autant que possible pour vous assurer que le comportement reste inchangé

Answer 3

Bonne question. Faites attention d'abord.