5 conseils pour choisir le bon code open source

Des études menées par Google montrent que pour de nombreux développeurs, trouver du code en ligne prend une grande partie de la journée. Trouver une fonction simple, une bibliothèque, un package utile, un composant réutilisable ou un tutoriel de blog "comment faire" utile n'est pas toujours simple. Savoir si vous pouvez faire confiance et utiliser le code que vous avez trouvé peut être encore plus délicat.

Trouver le bon code signifie généralement se tourner vers les dieux de Google ou d'autres moteurs de recherche, lancer une requête et croiser les doigts pour une victoire rapide. Des requêtes fonctionnelles simples telles que « Javascript a sa propre propriété » conduiront probablement à différents forums et articles de blog, tandis que des descriptions de niveau supérieur (« Composant React x ») vous mèneront souvent à GitHub ou NPM.

Cependant, même après avoir trouvé le bon code, faire confiance et l'utiliser est un tout autre problème. Pour vous aider à comprendre quel code vous pouvez réellement utiliser, j'ai rassemblé 5 paramètres qu'il peut être utile de prendre en compte. Prendre la bonne décision doit prendre en compte ces paramètres (entre autres), ainsi que la nature de la tâche elle-même. Voici les 5 clés que vous pouvez prendre en compte pour choisir le bon code.

#1. Le code est-il lisible ?

Un code lisible signifie bien plus que de bons commentaires et une bonne documentation. Cela signifie que le code lui-même doit être lisible pour vous. Différents paramètres de lisibilité peuvent être de bonnes conventions de nommage pour les identifiants, un bon espacement, une logique lisible claire, des portées bien comprises et plus encore. En fin de compte, le code doit être lisible pour vous . Lorsque vous choisissez un morceau de code, même un qui fonctionne, mais que vous ne comprenez pas parfaitement comment il fonctionne, vous introduisez essentiellement une bombe à retardement de maintenance dans votre base de code.

Le débogage, la modification, la mise à jour et la maintenance du code que vous ne pouvez pas lire sont des choses que vous devez absolument éviter. La meilleure façon de l'éviter sera de ne jamais le laisser en premier lieu lorsque cela est possible.

#2. Le code est-il activement maintenu ?

Nous voulons que le code que nous choisissons soit « vivant ». Cela signifie que nous voulons savoir que les bogues, les problèmes et les mises à jour sont traités et que ce code sera activement maintenu par les développeurs qui l'ont écrit. Un bon exemple d'indicateur d'activité peut être les problèmes ouverts, les demandes d'extraction et l'indicateur Pulse de GitHub. Les gestionnaires de packages fournissent des informations pertinentes pour la maintenance, telles que le nombre de dépendances et de projets dépendants, mais ont toujours du mal à présenter une métrique fiable dans ce domaine.

Néanmoins, si un grand projet populaire dépend d'un autre package, nous pouvons supposer que les problèmes ont une forte probabilité d'être résolus (cependant, nous nous souvenons tous du pavé gauche). Cependant, lors de la copie de code à partir d'un débordement de pile (ce qui est un problème en soi), vous n'avez aucun moyen de savoir que vous pouvez avoir confiance que ce code sera maintenu autre que de le mettre à jour vous-même chaque fois que nécessaire (et partout où vous l'avez dupliqué).

Les petites fonctionnalités de base ne changent tout simplement pas autant. Dans cet esprit, les composants réutilisables importés de Bit reposent sur un simple contrôle de version incrémentiel qui incrémente la version du composant de 1 à chaque fois que son auteur a modifié quelque chose. Garder vos composants dans une version « dernière mise à jour » signifie, avec de bons tests, que votre code peut être activement maintenu par son responsable tout en mettant à jour même de petites fonctions ou composants de votre code sans rien casser.

#3. Le code est-il bien testé ?

Choisir un code qui fonctionne est probablement notre première priorité. Les tests sont un excellent moyen de savoir si le code que j'utilise fait réellement ce qu'il est censé faire. La description des tests présente également différents cas d'utilisation et cas limites qui nous aident à savoir comment ce code se comportera dans différentes situations. L'utilisation de composants testés rend le logiciel plus facile à entretenir dans son ensemble, ce qui permet d'économiser du temps et des problèmes lorsque vous essayez de modifier des éléments avant de passer à la production.

Les extraits copiés sur le Web ne sont généralement pas accompagnés de tests. Rarement, voire pas du tout, les fonctions copiées à partir de forums ou de billets de blog incluront des tests unitaires. Les packages et les bibliothèques peuvent très bien être testés, le problème est de pouvoir le comprendre rapidement. Lors de l'exploration d'une bibliothèque sur GitHub, différents badges ou fichiers du référentiel peuvent indiquer dans quelle mesure et dans quelle mesure ce code est testé. Il faudra encore utiliser des indicateurs fournis par des outils externes pour savoir si les tests ont réussi ou non. Lors de la recherche d'un package, il n'y a pas vraiment de moyen fiable de savoir quel package est testé et si les tests ont réussi. C'est un gros problème lorsqu'il s'agit de découvrir les packages. Réutilisable

Lors de la recherche d'un package, il n'y a pas vraiment de moyen fiable de savoir quel package est testé et si les tests ont réussi. C'est un gros problème lorsqu'il s'agit de découvrir les packages. Les composants Bit réutilisables peuvent être testés si de tels tests sont ajoutés par le développeur. Le Bit Scope exécute le test afin que les indicateurs verts et la description des tests puissent être affichés en ligne avant de choisir un composant dans le hub communautaire Bit (ou via la CLI lorsqu'il est utilisé sur votre machine locale de manière distribuée).

#4. Le code est-il utilisé par d'autres ?

La popularité est quelque chose en laquelle nous avons confiance dans l'évolution. L'opinion publique est bonne pour prendre des décisions qui aident à notre survie. Si nous voyons tout le monde manger un certain fruit d'un arbre, nous savons que cela ne nous tuera probablement pas. Si nous voyons tout le monde fuir les buissons, un tigre affamé pourrait bientôt suivre. Dans une certaine mesure, il en va de même pour le choix du code en 2017.

Autour des forums de programmation, nous pouvons utiliser différentes indications telles qu'un "V" marquant les bonnes réponses, le nombre d'opinions vocales positives et vocales des utilisateurs. Ce sont des fonctionnalités excellentes et rassurantes pour augmenter la probabilité que le code fonctionne correctement. En ce qui concerne GitHub, nous pouvons compter sur des stars, des collaborateurs et d'autres mesures sociales pour avoir un sentiment de confiance. Lors de la recherche de packages, un bon indicateur serait le nombre de téléchargements pour ce package.

Les composants Bit trouvés sur le hub de la communauté Bit présentent le nombre de téléchargements, de collaborateurs (au niveau de la portée), de simples « j'aime » et plus encore (comme indiqué dans cette portée de composants React). Quoi qu'il en soit, gardez à l'esprit que les métriques sociales sont une bonne indication - mais une vérité absolue concernant la qualité du code. Les gens se trompent souvent et l'opinion publique peut changer plus vite qu'on ne le pense.

#5. Le code est-il bien documenté ?

La documentation rend le code beaucoup plus facile à comprendre, à utiliser et à modifier. C'est également une excellente indication de la réflexion et de la prudence du développeur qui a écrit le code. La documentation du code trouvé sur Stack Overflow ou différents articles de blog peut comprendre à la fois les commentaires dans le code lui-même ainsi que la réponse réelle ou le blog dans lequel il a été trouvé. Lorsqu'une réponse de forum inclut une élaboration utile sur le code qu'elle contient, cela pourrait très bien être une documentation qui vaut la peine d'être ajoutée même lors du copier-coller du code lui-même (encore une fois, veuillez ne pas copier-coller le code).

Pour les référentiels et packages GitHub, les choses sont un peu plus compliquées. Habituellement, les fichiers readme et docs présentés sur GitHub ou NPM fourniront une indication générale quant à la qualité de la documentation. La documentation des composants Bit est analysée à partir du code lui-même et affiche donc la description réelle du composant atomique, et peut également inclure des exemples d'utilisation et une signature spécifiée, y compris des arguments et des retours pour différentes fonctions et comportements pour les composants React et autres. Dans tous les cas, choisir un code documenté est une bonne décision chaque fois que cela est possible.

Pour les référentiels et packages GitHub, les choses sont un peu plus compliquées. Habituellement, les fichiers readme et docs présentés sur GitHub ou NPM fourniront une indication générale quant à la qualité de la documentation. La documentation des composants Bit est analysée à partir du code lui-même et affiche donc la description réelle du composant atomique, et peut également inclure des exemples d'utilisation et une signature spécifiée, y compris des arguments et des retours pour différentes fonctions et comportements pour les composants React et autres. Dans tous les cas, choisir un code documenté est une bonne décision chaque fois que cela est possible.

Prendre la décision

En fin de compte, la mémoire humaine est limitée et il ne sert vraiment à rien de réinventer la roue à chaque fois. Cependant, lors de la recherche et de l'utilisation d'un morceau de code open source, les indicateurs ci-dessus peuvent vous aider à vous assurer que votre application reste sécurisée, maintenable, fonctionnelle et en bonne santé.

Différents cas d'utilisation signifient donner un poids différent aux différents paramètres. Lors du choix d'un package, il sera difficile de savoir à quel point il est testé, lisible, documenté et activement maintenu. Lors de la copie de code à partir d'un forum en ligne, nous pouvons donner la priorité à la popularité plutôt qu'aux tests, à la maintenance, etc. Les composants binaires combinent des informations pertinentes pour l'importation et la réutilisation de composants et de fonctionnalités atomiques telles que la description, les exemples, les téléchargements, les dépendances, la description des tests, les résultats des tests, etc. En considérant attentivement ces différents paramètres, nous pouvons prendre une décision éclairée et traverser le labyrinthe de la recherche et du choix du bon code pour le travail.