Du hack du vendredi à la sortie : réflexions sur la création et la publication d'un projet Open Source-Golang-php.cn

From Friday Hack to Release: Reflections on Creating and Releasing a Open Source Project

Du Friday Patch Hack à la sortie : réflexions sur la création et la publication d'un projet Open Source

Ceci fait partie d'une série destinée aux développeurs débutants et intermédiaires, libérant ou intrigués par la publication de leurs idées sous forme de projets Open Source.
Ces réflexions sont biaisées et personnelles. D'autres articles sont prévus. En partageant quelques réflexions, j'espère vous inspirer à réaliser vos propres projets

Réflexions (ceci)
Apprendre Go Lang en tant que développeur Java (TODO)
Fichiers Open Source Santé et Communauté (TODO)
Sécurité Open Source (TODO)

Les besoins

Tout a commencé il y a des années. J'avais de temps en temps besoin de quelque chose qui semblait toujours impliquer de recréer le même vieux script Bash, soit par moi, soit par quelqu'un d'autre.
Les exigences globales étaient simples, car elles sont souvent de haut niveau.
Ce que nous, les développeurs, faisons principalement, c'est simplement déplacer des informations d'un point A à un point B, n'est-ce pas ?

Ici, l'objectif était de mettre en miroir un ensemble de référentiels Git - vers un autre fournisseur Git, sur disque, dans un format d'archive, dans une application CLI.
J’en avais besoin en privé et dans mon rôle professionnel. J'ai vu des gens avoir du mal, investir beaucoup de temps à faire ces choses manuellement, et cela me dérange.

Pourtant, cela a toujours semblé rester un simple script Bash. Rapidement fait, mais dès que quelque chose de plus devait être ajouté - cas particuliers, gestion des erreurs, modularisation, packaging, etc. - les scripts Bash ne résistent pas aux outils plus gros, comme la plupart d'entre nous en conviendraient.

J'ai donc décidé de créer une application CLI complète pour cela.

Les pré-décisions à prendre

Un tel outil existe-t-il déjà ?

La première chose à faire était de ne pas réinventer la roue.
Il existe quelques outils Open Source qui résolvent ce problème. Au moins un écrit en Go, quelques scripts Bash, et si l'on compte les fonctions d'importation comme celle de Gitea.
Je les ai essayés, mais je n’en ai trouvé aucun qui fonctionnait pleinement comme je le souhaitais. Et comme j'avais d'autres idées sur l'endroit où je voulais amener le projet, j'ai décidé de ne pas m'y plonger en profondeur
commencer à appliquer des correctifs aux projets existants.

Il existe également quelques outils commerciaux, mais j'ai pensé que ce petit outil est quelque chose qui devrait également exister dans les formulaires Open Source.

Conclusion : Il y avait une place pour cet outil CLI dans ce monde.

Le pirater lors des journées de travail ou pendant votre temps libre privé ?

Nous avons des temps de hacking au travail à la fin des sprints et à d'autres occasions. Une approche serait de le pirater au cours de ces occasions au fil du temps, pour en faire quelque chose d'utile.
J'ai rapidement décidé de le faire pleinement pendant mon temps libre privé, pour les raisons suivantes :

Les opportunités de hack au travail doivent être utilisées pour de courtes périodes d'apprentissage et de créativité, et non pour la réalisation à long terme d'un projet complet.
La solution ne correspond pas aux activités principales de l'organisation - ce serait toujours un canard étrange si tel était le cas.
Lier cela au travail donnerait l'impression d'avoir juste plus de travail - je fais ça pour m'amuser et apprendre le Go, etc. - cela me mettrait de la pression et du stress.
Le faire les jours de travail prendrait une éternité. Quelques heures, réparties sur des semaines.

Conclusion : Je devrais le faire pour m'amuser pendant mon temps libre.

Choix de la pile technologique

J'ai passé la plupart de mon temps au fil des années dans le monde Java/Kotlin, avec quelques projets en JS/TS, Python/Ruby et, comme tout développeur senior, en m'attaquant parfois à d'autres choses.
Mais depuis longtemps, je voulais vraiment apprendre Go et/ou Rust. Ce serait donc l'occasion d'avoir la motivation de se plonger dans une nouvelle langue
La raison pour laquelle j'ai choisi Go est que de nombreuses applications CLI dans le monde Open Source DevOps y sont écrites, et je souhaite parfois pouvoir soumettre des correctifs à des projets tiers. De plus, écrire en Go signifie un binaire avec de nombreuses architectures cibles.

J'aurais pu faire cela en Java, par exemple, avec Pico CLI et GraalVM dont j'avais une bonne impression depuis les essais précédents mais j'ai décidé que je voulais vraiment apprendre Go à la place.

Conclusion : Je devrais le faire dans Go et en tirer des leçons.

Autres objectifs d'apprentissage

Avec cela, je voulais également approfondir les sujets liés à la livraison d'un projet Open Source bien emballé, en suivant la plupart des pratiques de sécurité - tableaux de bord, SLSA,

et utiliser des outils comme GoRelease pour créer des builds de différents types.

Conclusion : Profitez de l'occasion pour apprendre et approfondir les sujets de votre choix.

Gardez la portée

Comme j'avais prévu d'expérimenter beaucoup et que j'étais totalement nouveau sur Go, je savais que je ferais beaucoup de travail non structuré.
Ici, il était important de définir la portée : quand serait-ce suffisant pour une version alpha ?
J'ai très tôt décidé des fonctionnalités qu'il devrait avoir, et aussi tentant que cela puisse être de l'affiner et de l'étendre davantage, c'était bien.
Je pourrais rester longtemps avec ça.

Conclusion : Libérez le projet en alpha lorsque vous en êtes également gêné et fier.

Estimation : à quel point cela peut-il être difficile ?

Apprendre une nouvelle langue n'est qu'une petite partie de l'apprentissage de la langue elle-même, mais bien plus de l'apprentissage de l'écosystème et de ses idiomes.
Quelles bibliothèques sont utilisées, comment sont-elles utilisées, quelles sont les manières idiomatiques de faire ceci et cela ?
Je devrais passer beaucoup de temps à apprendre et à faire des recherches pendant ce projet, peut-être 50 % du temps
j'ai passé juste à coder dans un langage et un écosystème que je connais.

Conclusion : Multipliez votre estimation de temps par trois lorsque vous apprenez de nouvelles piles de base et impliquez des expérimentations. La syntaxe du langage sera une petite chose.

Le processus de création

Engagement initial

L'implémentation de base a été réalisée en une journée - elle n'avait pas de builds, de gestion des erreurs, de documentation, de cas extrêmes, de maintenabilité, etc.
C’est là que aboutissent la plupart des hacks du vendredi, et la plupart d’entre eux ne vont jamais plus loin.

Mais comme tous les développeurs seniors le savent, faire fonctionner quelque chose est bien loin de la sortie d'un produit.

Bientôt fini, hein ? Pas vraiment.

Trouver le temps

Parfois, c'était très difficile de trouver du temps à consacrer au projet, d'autant plus que j'avais un printemps épuisant au travail.
Ce n'est pas tous les soirs que l'on a envie de lire un livre pendant 2 heures sur quelque chose de précis, ou d'apprendre une nouvelle technologie.
Ou passer du temps à rédiger de la documentation. J'ai des enfants et une maison, et je ne pouvais pas me permettre de laisser un projet privé me consommer plus que d'autres passe-temps.
Mais quelque chose doit toujours céder - j'ai fini par regarder moins de séries et aucun jeu n'a été quasiment inexistant pendant cette période.

Cela dit, même si j'aurais aimé pouvoir consacrer plus de temps sur le projet, c'était presque toujours motivant - j'ai eu quelques séances nocturnes où j'ai moins dormi et codé ou étudié,
parce que j'étais tellement excité d'aller plus loin. De plus, quand quelque chose est amusant, c'est amusant, qu'il s'agisse de soulever des poids, d'écrire un livre, de se développer, etc.

Les choses que j'ai oubliées

Je suis tellement habituée à travailler en équipe depuis longtemps. Avec un projet solo, il faut gérer beaucoup plus de chapeaux et être plutôt bon dans chaque partie, pas souvent technique.
J'ai passé beaucoup de temps à étudier une bonne conception CLI et des choix idiomatiques. Un autre domaine était le processus de publication et la création de binaires pour différentes plates-formes.
Suivre SLSA et d’autres normes Open Source a également pris du temps. Et nous voulons une bonne couverture des tests, n'est-ce pas ?
En travaillant en équipe, quelqu'un d'autre réalisera, espérons-le, le logo que vous vouliez, la documentation nécessaire à la rédaction.
Travailler en solo, c'est seulement toi ou ça n'arrivera pas.
L'écriture de code ne représente même pas 50 % de la réalisation d'un projet. Et voilà le reste.

Le syndrome de l’imposteur frappe

Le syndrome de l'imposteur est courant dans notre monde de développeurs basé sur la connaissance. Tout le monde a des compétences différentes et, à tout moment, il y aura toujours quelqu'un qui en saura plus que vous.
Étant dans une équipe, vous avez quelqu'un avec qui discuter.
Seul, pas autant.

Mais il s'agit avant tout d'accepter qu'on fasse parfois des bêtises dans le code.
Et cet Open Source ne consiste pas à être parfait. Il s'agit d'apprendre, de résoudre et de libérer des choses qui pourraient être utiles aux autres.

La mouture

Eh bien, que puis-je dire - c'est fait quand c'est fait.

Il y a eu quelques nuits de débogage, de refactoring, mais aussi d'innombrables moments de flow et de dopamine.

Pour moi, le moment de la sortie est arrivé lorsque j'ai senti que l'architecture globale du projet ne bougerait pas radicalement - j'avais identifié les interfaces et j'ai senti qu'elles étaient extensibles.
La base de code est OK.
La plupart des fonctionnalités de base sont là, et même si tout est à améliorer, cela reste une base sur laquelle travailler.

Les conséquences et les leçons apprises

Définissez la portée dès le début : Décidez où vous arrêter. Configurez tôt la structure, la documentation, les versions, les pipelines et les directives de la communauté de votre projet. Avenir tu remercieras passé toi.
Ne stressez pas, profitez du processus d'apprentissage : C'est fait quand c'est fait.
Soyez persévérant : L'open source est un marathon, pas un sprint. Ne vous épuisez pas. C'est un passe-temps, pas votre vie. Soyez néanmoins persévérant. Faites une petite chose chaque jour.
Apprendre, apprendre, apprendre : Voyez tout comme une opportunité d'apprendre et de vous améliorer, pas comme un problème.
Le codage est la partie la plus facile : Le code principal est ce qui vous prendra le moins de temps ; tout le reste, comme la documentation, les tests, etc., est l'endroit où l'on passe du temps.
Faites les extras : Ils sont aussi amusants que coder. Oui, même la documentation peut vous épargner des heures d’explications et de réexplications. Amusez-vous si vous vous ennuyez. Docs-as-code, vim-pong, etc.
Faites des pauses : Le burn-out est réel. Prenez du recul lorsque vous en avez besoin. Comme tout autre processus d’apprentissage créatif, faites-le par lots.
Utilisez le système : Utilisez votre propre nourriture pour chiens dans la pratique et dans le monde réel le plus tôt possible. Mieux encore, trouvez une personne/une communauté pour donner son avis.
Profitez du voyage :C'est merveilleux de créer.
Complétez-le : Il y a des millions de projets à moitié réalisés dans ce monde. Complétez-le.
Utiliser l'IA comme aide : Je gagne des heures en lui déléguant quelques extras, comme demander des améliorations du code, des révisions de code, des structures de documentation, des résumés, etc. Cependant, ne le faites pas faites-lui toujours confiance aveuglément. Examinez et critiquez les réponses.