Article original : How to use GitHub badges to stop feeling like a noob
Par Cam Barts
Le syndrome de l'imposteur est réel et il tourmente les nouveaux développeurs. Nous suivons des tutoriels, des bootcamps, voire même un diplôme, mais nous hésitons toujours à partager notre code. Nous craignons les retours négatifs sur la qualité de notre code. Personne ne souffre plus de cela que les développeurs autodidactes. Parce que nous n'avons aucune expérience ou formation "réelle" ou "officielle", nous considérons notre code comme étant de mauvaise qualité.
J'étais dans cette situation il y a quelques mois. Je travaillais sur Test-Driven Development With Python de Harry Percival. Même si je suivais bien le tutoriel, j'étais gêné à l'idée de partager mon code. Même si mon application fonctionnait comme prévu, je ne voulais pas partager mes progrès. Je ne voulais pas que quelqu'un me signale une erreur évidente à laquelle j'étais aveugle. Je voulais que les autres apprécient mon produit, mais je ne voulais pas qu'ils voient à quel point j'étais un mauvais développeur.
Après avoir fait une pause dans mon propre projet, j'ai commencé à regarder d'autres projets sur GitHub. J'en ai trouvé quelques-uns qui avaient une petite image sur leurs pages README.
À l'époque, étant un débutant, je pensais que c'était simplement une image que Linus Torvalds vous remettait sur une clé USB lorsque vous sortiez de l'école des "Vrais Développeurs". Il ne m'est jamais venu à l'esprit de cliquer dessus. Je pensais que c'était une image statique hébergée quelque part dans le dépôt. Plus tard, je suis tombé sur un projet qui affichait que la construction avait échoué.
Pourquoi quelqu'un prendrait-il le temps d'ajouter une image qui dit que leur construction ne passe pas ? Pourquoi faire l'effort d'enlever l'autre image pour mettre celle-ci ? Une image qui dit que votre projet est cassé et l'afficher pour que le monde entier la voie ? Par pure curiosité, j'ai ouvert le format brut du README. J'ai vu ce code :
[](https://travis-ci.com/username/projectname)
J'étais suffisamment familiarisé avec le markdown pour reconnaître qu'il s'agissait d'un lien cliquable. J'ai donc cliqué sur le bouton et il m'a emmené à Travis-CI. Tout à coup, cela a eu du sens pour moi. Ce bouton n'était pas mis à jour par le développeur du projet, Travis-CI le mettait à jour. C'est un bouton dynamique.
Mon Premier Badge
Ainsi, une fois que j'ai découvert le badge de construction de Travis-CI, j'ai dû l'avoir pour mon projet. Après tout, mon projet entier était consacré à l'écriture et à l'utilisation de tests. Alors pourquoi ne pas avoir quelque chose qui les exécute automatiquement ?
J'ai donc configuré Travis-CI pour exécuter mes tests unitaires lorsque je poussais des changements vers GitHub. Tout en haut de la page où Travis-CI les exécute, se trouve le badge. J'ai cliqué dessus et obtenu le markdown. Je l'ai ajouté à mon README. J'ai navigué vers la page du projet sur GitHub et VOILÀ ! Mon premier badge était là. J'étais accro !
La Chasse
J'ai apprécié que le badge soit un signe clair de l'état actuel de mon projet. Je voulais en savoir plus, alors je suis parti à la chasse aux autres badges. Un autre badge courant que j'ai trouvé était la couverture de code. Le rapport de couverture pouvait être envoyé par Travis-CI à un outil appelé CodeCov. Vous pouviez obtenir un badge indiquant la couverture de vos tests, ce qui correspond à la qualité des tests de votre application.
J'ai également trouvé des badges de licence, et il était logique d'avoir un badge de licence si j'avais une licence. J'ai donc choisi une licence et je l'ai ajoutée au dépôt. Obtenir le badge pour cela a nécessité une rapide recherche Google, et j'ai trouvé ce gist avec tous les badges de licence courants.
Venant d'un milieu militaire avec une formation en sécurité, je sais que la plupart des vulnérabilités proviennent de logiciels obsolètes. En tant que nouveau développeur, je sais que cela s'applique également aux logiciels dont dépend votre logiciel. J'ai entendu parler de PyUp grâce au podcast Talk Python to Me de Michael Kennedy. Lorsque j'ai navigué vers le site, j'ai vu les mots que j'avais commencé à aimer voir, "Gratuit pour l'Open Source". Étant à la chasse aux nouveaux badges, j'ai eu de la chance. En effet, ils fournissent un badge, alors bien sûr, je l'ai ajouté au README.
Enfin, j'ai découvert que vous pouviez avoir un badge pour le style. J'avais déjà joué avec Black auparavant, et j'ai trouvé un exemple de badge de style et j'ai su que je devais l'avoir. Pour l'amour de mon intégrité, je voulais m'assurer que mon code était toujours conforme au style de Black. J'ai découvert pre-commit, que je pouvais utiliser pour formater mon code avant même de le commiter. Après avoir plongé dans le terrier de pre-commit (qui exécute également mon code contre bandit pour la sécurité et trie mes imports et mes dépendances), je me suis senti confiant pour ajouter le badge Black à mon README.
Le Résultat Final
Le premier résultat de la chasse aux badges est que mon projet est de meilleure qualité. J'ai ajouté une licence à mon projet, j'ai veillé à ce que mes dépendances restent à jour et j'ai maintenu le style de mon projet conforme parce que je voulais les badges.
Plus notablement, j'ai plus confiance en mon projet. Je peux en parler en sachant qu'il n'y a pas de failles béantes. Je sais que je suis beaucoup moins susceptible de recevoir des retours sur mon irresponsabilité en matière de sécurité ou mon manque de conformité de style.
Pour faire simple, je me sens mieux à propos de mon code parce que j'ai ces badges GitHub.