4 grandes leçons de mon stage avec l'open source

Quelques mois seulement après m'être lancé dans l'open source, j'ai appris des leçons en tant que stagiaire universitaire qui aideront toute personne écrivant et contribuant au code d'une communauté.

Si vous possédiez une machine à voyager dans le temps et choisissiez de vous tirer un an en arrière pour me demander ce que je pensais de la contribution à l'open source (parmi tout ce que vous auriez pu faire), vous auriez peut-être deviné que je hausserais simplement les épaules et dirais quelque chose du genre : « Je ne sais pas, n'est-ce pas réservé à tous les développeurs endurcis avec les statistiques insensées de GitHub et les macros ornées et tout ça ? Je n'aurais aucune idée de ce que je faisais, et qui se soucierait même de ce qu'un étudiant au hasard avait à dire à propos de son code ? » Et vous auriez probablement raison. Mais c'était tout cela avant que je tombe sur l'incroyable opportunité de faire un stage chez Red Hat au sein de la division OpenShift Engineering pendant la majeure partie de 2020.

Je suis arrivé au stage comme n'importe quel nouvel étudiant en informatique, contournant ma vie en écrivant du code non testé, à peine lisible mais toujours fonctionnel, et en étant fier. Mais ce stage m'a donné l'opportunité de me familiariser avec la culture open source et enfin de voir de quoi parle tout ce battage médiatique.

J'ai travaillé au sein de l'équipe OpenShift-GitOps à peu près au moment où Red Hat a officiellement adopté Argo CD dans son écosystème. Par la suite, j'ai été chargé, avec le reste de l'équipe, d'apporter des contributions en amont à Argo CD. J'ai décidé de partager certaines de mes réflexions sur mon expérience dans un article pour vous la faire découvrir.

Comprendre les choses

Comme on pouvait s’y attendre, les débuts ont été difficiles et désorientants. Je pense que nous pouvons tous convenir que lire du code est déjà assez difficile lorsqu'il est écrit par un collègue de votre équipe. Se familiariser avec du code écrit au sein d'une autre organisation, l'utilisation potentielle de différentes technologies, de différents composants et de différentes pratiques de codage peut rapidement s'avérer écrasant. À plusieurs reprises, je me suis retrouvé à parcourir des fichiers sans réfléchir.

J'ai vite réalisé que ma première étape aurait dû être d'essayer de comprendre le produit en tant qu'utilisateur, et non en tant que développeur. Cela impliquait d'essayer de rendre le logiciel opérationnel et de jouer avec. Heureusement, j'avais toute une équipe qui vivait la même chose, nous pouvions donc nous aider mutuellement à nous installer et à nous y retrouver.

C'est également à ce moment-là que j'ai commencé à apprécier le pouvoir d'une bonne documentation et ce qu'elle peut faire pour vous simplifier la vie en tant que développeur. En prime, les bonnes personnes de la communauté Argo ont été suffisamment accommodantes pour organiser une sorte d'heure de bureau hebdomadaire pour faciliter l'accueil de tous les nouveaux contributeurs. Ces sessions ont grandement contribué à accélérer la phase d'installation délicate et à aider l'instinct de notre programmeur à intervenir plus tôt. (C’était aussi un endroit idéal pour être un observateur instantané.)

Sélection et résolution des problèmes

En avançant un peu, j'ai commencé à parcourir la liste des problèmes en suspens à la recherche de quelque chose dans lequel m'enfoncer les dents. Cela peut être un processus compliqué. La forte dépendance de la communauté open source à l'égard de la propension à participer de ses membres s'accompagne de son lot d'ambiguïté et du manque d'obligation de communication efficace. Cela peut se présenter de plusieurs manières, par exemple une incapacité à reproduire localement le problème décrit, un contexte insuffisant pour comprendre le problème ou simplement une communication extrêmement lente avec la personne qui a soulevé le problème. Au fur et à mesure de votre expérience open source, vous constaterez peut-être qu'il s'agit d'un thème récurrent. Cependant, cette expérience m'a aidé à réaliser que choisir le bon problème, comprendre sa sémantique et le reproduire localement représente la moitié de la bataille.

Lorsque les choses se passent bien et que vous trouvez un problème intéressant avec un engagement décent, cela peut être très excitant ! Les discussions dans la section commentaires peuvent montrer les différents cas d'utilisation et les solutions de contournement proposées par les utilisateurs concernant des problèmes spécifiques du projet. Celles-ci peuvent être d’excellentes sources de contexte, et la collecte de contexte est la clé du jeu, du moins jusqu’à ce que vous sachiez ce qui se passe.

Une fois que j'étais dans les mauvaises herbes et que je commençais à réfléchir à des solutions potentielles à un problème, ce qui m'a le plus frappé était la courbe d'apprentissage associée à chaque nouveau problème que j'abordais. L'une des raisons était que je choisissais au hasard parmi les problèmes ouverts non réclamés déposés lors de la prochaine étape majeure de la version. Cela signifiait que les problèmes que j'avais abordés variaient beaucoup. Je finirais par descendre dans un terrier de lapin différent pour chacun, apprenant 10 nouveaux concepts connexes au cours du processus (même si tous n'ont pas été intégrés à l'éventuelle demande d'extraction).

La même chose était vraie même lorsque l'on essayait de parcourir le code pour retrouver la source d'un bug et de découvrir tous les différents composants impliqués. Cette phase a toujours semblé être la plus riche en apprentissages. Au fur et à mesure que j’avançais lentement vers la solution, j’avais souvent besoin de combler certaines lacunes dans mes connaissances. Encore une fois, je crois avoir eu les collègues les plus solidaires que l’on puisse espérer puisque je pouvais toujours les consulter au besoin.

Soumettre des demandes de tirage

Une fois qu'un correctif ou une fonctionnalité est effectué et testé localement, vous êtes prêt à lancer votre pull request (PR) ! Ceci est généralement suivi de quelques allers-retours avec les responsables du référentiel pendant qu'ils examinent votre PR et demandent éventuellement des modifications. Cela m’étonne toujours de penser au temps, aux efforts et aux délibérations que peut impliquer la plus petite contribution. Cela n'est pas toujours évident de l'extérieur, et votre PR pourrait finir par être très différent de ce avec quoi vous avez commencé.

J'ai également appris qu'il n'est pas rare que cinq lignes de modifications de code soient accompagnées de 150 lignes de tests pour ces modifications. En d'autres termes, l'écriture de tests unitaires pour votre PR peut parfois être tout aussi complexe que le correctif/la fonctionnalité lui-même, sinon plus. Une fois que tout est dit et fait, votre PR est enfin fusionné. Vous pouvez faire une danse de célébration rapide, mais ensuite passez à la suivante !

Apprendre de grandes leçons

J'ai beaucoup appris lors de mon stage qui m'aidera professionnellement et personnellement.

Cours professionnels

En arrivant là-bas, la plupart de mon expérience en codage avait été centrée sur des projets personnels ou des devoirs pour l'école ou des tâches assignées à mon organisation. Celles-ci ont tendance à être très spécifiques à leur public cible et n'ont généralement pas beaucoup de conséquences pour la communauté au sens large. En revanche, les projets open source ont tendance à avoir une portée beaucoup plus large, il était donc intéressant de réfléchir à l'ampleur potentielle de l'impact de mes contributions. Cela m’a donné l’impression que mon travail avait des conséquences, et cela en valait la peine.
Si vous êtes comme moi, trouver des problèmes aléatoires et les résoudre peut ne plus être aussi excitant après un certain temps. Vous pourriez vous demander : "À quoi tout cela mène-t-il réellement ?" C’est pourquoi je pense qu’il est important d’avoir une vision plus large et une orientation à l’esprit. Il vous aide à prendre des décisions et vous rappelle l'objectif vers lequel vous travaillez. Les objectifs plus larges de Red Hat et sa vision à long terme pour l'adoption d'Argo CD m'ont donné ce sens de l'orientation et m'ont aidé à rester motivé. Mais cela peut probablement être réalisé de plusieurs manières. Choisir et travailler sur des problèmes de manière plus stratégique, afin qu'ils vous permettent d'apprendre un aspect de la programmation que vous souhaitez améliorer, pourrait en faire partie.

Cours personnels

Ce n’est un secret pour personne : se lancer dans quelque chose de nouveau peut être intimidant. Comme probablement la moitié de l’industrie du logiciel, je ne suis pas étranger au syndrome de l’imposteur. Il y avait des moments où j’avais l’impression de ne pas avancer aussi vite ou de ne pas faire autant de progrès que je l’aurais attendu de moi-même. C’était frustrant, mais j’ai finalement compris à quel point il est important d’être patient avec soi-même. Surtout si vous êtes quelqu'un qui vient tout juste d'apprendre les ficelles du métier, cela peut prendre un certain temps avant de commencer à faire de bons progrès, mais il convient de rappeler que tout cela fait partie du processus d'apprentissage.
Au début, j'avais tendance à me comparer à mes collègues plus expérimentés qui rencontraient des problèmes et fusionnaient les PR plus rapidement qu'on ne pouvait finir de dire "Argo CD". Cela n’a pas beaucoup amélioré ma confiance, mais j’ai réalisé que me comparer (un stagiaire travaillant à temps partiel) à des vétérans de l’industrie n’était vraiment une comparaison équitable pour personne. La meilleure façon de vous développer est de vous comparer à ce que vous étiez plutôt qu’à ceux qui vous entourent.

Autres conseils utiles que j'ai appris

N'hésitez pas à poser des questions sur le forum communautaire. Essayez également de savoir si le projet dispose d'un Slack, Discord ou Gitter auquel vous pouvez rejoindre.
Consultez d'autres PR et discussions pour obtenir le contexte de ce qui se passe dans le projet et mieux comprendre la base de code.
Essayez d'identifier les messages de journal et d'erreur uniques liés au flux de travail qui vous intéresse. La recherche de ces messages directement dans la base de code pourrait être un moyen rapide de localiser la zone sur laquelle vous souhaitez vous concentrer et de procéder à une ingénierie inverse de la séquence d'appels de fonction. impliqué pour arriver à ce point peut vous aider à comprendre tout ce qui se passe en cours de route. (J'ai trouvé cela particulièrement utile.)
Examiner les tests unitaires peut être un bon moyen de comprendre ce qu'une fonction est censée faire et comment elle interagit avec d'autres fonctions (formats d'entrée/sortie, etc.).
La recherche de numéros étiquetés « bon premier numéro » pourrait être un bon point de départ. Cependant, il peut y avoir de nombreux bons problèmes qui ne sont pas étiquetés comme tels, il peut donc être intéressant de parcourir le tableau des problèmes en dehors de ce filtre.
Mettez toujours à jour la documentation si vous apportez des modifications à des fonctionnalités !

Pensées finales

L'expérience de contribution open source n'est pas un processus parfait. Comme toute autre chose, cela a ses inconvénients. Le sentiment d'ambiguïté dû à sa nature ouverte et au manque occasionnel de retour d'information ou de communication peut être difficile à contourner. D’un autre côté, je suis heureux de voir à quel point j’ai pu grandir et être exposé pendant cette période. J'ai trouvé stimulant et gratifiant de faire partie d'une équipe de développeurs, et je m'en porte mieux.

Travailler dans un paradigme différent, faire partie de la communauté plus large des développeurs et établir de nouvelles connexions étaient tous de grands avantages. La fusion de vos PR est également un bon sentiment ! J'ai également bénéficié de la découverte de PlayerUnknown's Battlegrounds en tant qu'utilisateur d'Argo CD, et j'ai aidé à améliorer l'expérience de jeu PUBG de mes amis en leur en parlant.

Si vous êtes allé jusqu’au bout, merci d’avoir lu ! J'espère que cela pourra vous être utile pour commencer votre propre voyage dans le monde open source. Bonne chance!