Évitez d'incorporer des bibliothèques externes dans votre projet

Vous pouvez souvent entendre la phrase: «Pourquoi écrire votre vélo? Prenez une bibliothèque prête à l'emploi et utilisez-la! Tout a déjà été écrit pour vous. " Les développeurs novices entendent de telles expressions en particulier. Lorsqu'ils résolvent un problème, ils commencent à regarder des bibliothèques prêtes à l'emploi et à les intégrer sans réfléchir à leur projet. Dans cet article, vous apprendrez ce que peuvent entraîner les conséquences d'une introduction irréfléchie de bibliothèques tierces.



Problèmes potentiels



Je recommande fortement d'éviter d'ajouter des bibliothèques externes à votre projet. Cependant, cela ne signifie pas que l'utilisation de bibliothèques est maléfique, et votre fichier Gradle doit être complètement nettoyé de toutes les dépendances externes! Je veux transmettre l'idée qu'une analyse très sérieuse doit être effectuée avant d'ajouter une nouvelle bibliothèque. Pour comprendre comment analyser les bibliothèques, examinons certains des problèmes potentiels que vous pourriez rencontrer lors de l'ajout d'une nouvelle bibliothèque à votre projet.



Taille de l'application



La plupart des bibliothèques n'augmentent pas considérablement la taille de votre application. Mais il existe de telles bibliothèques, après l'ajout, votre application augmentera considérablement! Par exemple, la bibliothèque Realm peut augmenter la taille de l'APK de 4 Mo à 12 Mo. En moyenne, l'application pèse 100 Mo à 200 Mo et les 8 Mo supplémentaires peuvent ne pas être visibles. Mais gardez à l'esprit que Realm n'est pas la seule bibliothèque à avoir un impact négatif sur la taille de l'APK. Est-il possible de réduire la taille de l'APK en utilisant cette dépendance? Oui, vous pouvez diviser apk par architectures de processeur. Mais cela conduit au problème suivant (point 2).



Maintenabilité du code



Les projets grandissent, sont couverts de plus en plus de logique et parfois il devient plus difficile de les comprendre. Pour qu'après plusieurs années de développement de projet, tout nouveau développeur puisse facilement s'habituer au projet, une architecture de projet claire est nécessaire. Cependant, certaines bibliothèques peuvent annuler la maintenabilité du projet. Par exemple, un travail incorrect avec EventBus peut considérablement perturber la logique de votre application. Il est important de distinguer clairement entre où et dans quels cas vous utilisez cette lib. Et aussi pour être sûr que personne ne dérogera jamais à ces règles. Mais que se passe-t-il en pratique? Presque tous les développeurs commençant par EventBus l'utilisent partout. En conséquence, le projet devient complètement illisible.



Il est temps d'explorer la bibliothèque



Lorsque vous ajoutez une nouvelle bibliothèque, vous devez apprendre à interagir avec elle. Il existe des bibliothèques qui peuvent avoir un impact très négatif sur la vitesse de développement à l'avenir.

Par exemple, la PagingLibrary de Google demande beaucoup d'efforts pour comprendre comment interagir avec elle. Il faudra de 12 à 20 heures à chaque nouveau développeur pour comprendre cette bibliothèque. Vous perdez presque 3 jours! En seulement 3 jours, vous pouvez noter votre pagination et être indépendant des solutions tierces.



Vitesse de construction



La vitesse de construction des applications modernes est médiocre. Cependant, si vous souhaitez augmenter encore plus votre temps de construction, utilisez Dagger ! Je ne sais pas pourquoi la bibliothèque est encore activement utilisée après l'avènement de Kotlin. Dans la plupart des cas, Dagger contient les 4 problèmes décrits ci-dessus.



Bugs, bugs, bugs ...



D'après mon expérience, dans un seul projet, j'ai scié 5 bibliothèques en raison de la présence de bogues. N'oubliez pas qu'il y a presque toujours des bogues dans les bibliothèques. Par exemple:



  • AndroidPdfViewer laisse des fuites de mémoire, gère de manière incorrecte certains cas avec null, ce qui provoque la levée d'une exception NullPointerException
  • Le composant de navigation Android ne fonctionne pas correctement avec les animations Shared Elemant dans certains cas
  • Cicerone plante parfois l'application en raison deexecutePendingTransactions()


Cela signifie-t-il que les bibliothèques ne valent pas la peine d'être utilisées? Non, les bibliothèques peuvent et doivent être utilisées, mais il est important au moins de s'assurer qu'il n'y a pas de bogues critiques pour votre projet dans la liste des problèmes.



Vulnérabilités dans la bibliothèque



Connaissez-vous le moyen le plus simple de pirater plusieurs applications à la fois en examinant un seul code source? Nous devons trouver un bogue dans une grande bibliothèque utilisée par de nombreux développeurs. Et grâce à cette vulnérabilité pour accéder aux données de votre application. Si vous ne développez pas une application nécessitant une attention accrue à la sécurité des utilisateurs, vous pouvez fermer les yeux sur ce point. Sinon, recherchez un problème qui corrige les vulnérabilités potentielles.



Support de la bibliothèque



Si la bibliothèque n'a pas été mise à jour depuis un an, posez la question de savoir si cela vaut la peine de l'utiliser. Le fait est qu'il y a régulièrement des bogues dans les bibliothèques. Si ces bogues ne sont pas corrigés, vaut-il la peine d'utiliser cette bibliothèque? Il est fort possible que dans un proche avenir, vous tombiez sur un bogue de la bibliothèque et que vous deviez chercher des moyens alternatifs pour implémenter la fonctionnalité. Certaines bibliothèques doivent s'adapter aux capacités de l'API Android actuelle. Par exemple, si un nouvel élément est apparu dans Android, vous devez en ajouter la prise en charge. Ces bibliothèques incluent Anko , qui n'est plus prise en charge. Maintenant, cela n'a aucun sens d'utiliser cette bibliothèque dans de grands projets.



La bibliothèque est présente dans toutes les couches du projet



Les bibliothèques telles que RxJava ou PagingLibrary obligent le développeur à utiliser leur API sur chaque couche de l'application. Si vous êtes sûr que la bibliothèque sera toujours dans le projet, il n'y a pas de problème. Mais si, pour une raison quelconque, vous devez supprimer la bibliothèque, vous dépenserez des efforts colossaux! Vous devrez réécrire la moitié du projet.



Limitations de la bibliothèque



Chaque bibliothèque fournit une API qui est limitée à la fois par la disponibilité des méthodes publiques et par l'implémentation interne. Assurez-vous que les capacités de la bibliothèque vous suffisent. Par exemple, la bibliothèque populaire de composants de navigation Android lie très étroitement les mains du développeur. Il ne fournit pas de méthodes show, hide, add (dont FragmentTransaction a). De plus, la bibliothèque complique le travail avec BottomNavigationView lorsqu'il est nécessaire de stocker l'historique des onglets.



Énorme fichier Gradle avec dépendances



Quand j'arrive à un nouveau projet, la première chose que je fais est de regarder les dépendances dans le fichier Gradle. Il indique clairement ce que l'application peut faire et comment certaines tâches sont résolues. Mais j'ai été surpris quand j'ai vu que OkHttp, Retrofit et Volley (fork) sont utilisés pour travailler avec le réseau. Et ce n'est que du réseautage. Le fichier Gradle lui-même se compose d'un grand nombre de bibliothèques dont le support a pris fin il y a longtemps. Lorsqu'un développeur est seul, il peut garder tout le projet dans sa tête, mais lorsque de nouveaux développeurs arrivent, il devient extrêmement difficile de comprendre un tel projet.



Liste de questions avant la mise en œuvre de la bibliothèque



  1. Quel est le problème de cette bibliothèque? Sont-ils essentiels à mon projet?
  2. Dans quelle mesure cette bibliothèque / technologie est-elle testée par la communauté des développeurs? Combien d'étoiles a-t-elle sur GitHub?
  3. À quelle fréquence un développeur répond-il à un problème?
  4. À quelle fréquence le développeur met-il à jour la bibliothèque?
  5. Combien de temps les nouveaux développeurs passeront-ils à apprendre la technologie utilisée?
  6. Comment la bibliothèque affectera-t-elle la taille de l'application?
  7. Comment la bibliothèque affectera-t-elle la vitesse de l'application?
  8. Comment la bibliothèque affectera-t-elle la vitesse de construction? Cela vous aide-t-il à gagner du temps de développement?
  9. La bibliothèque présente-t-elle des vulnérabilités?
  10. La bibliothèque sera-t-elle présente sur chaque couche du projet? À quel point est-ce critique?
  11. Comment la bibliothèque limite les options du développeur (elle limite presque toujours). Est-ce bon ou mauvais?
  12. Pourrai-je rédiger moi-même une solution qui sera affinée pour mon projet dans un délai raisonnable?


Il est très intéressant d'entendre ce que vous pouvez rechercher d'autre lors du choix d'une bibliothèque. Dans l'attente de vos commentaires, commentaires et questions!



All Articles