Dari Friday Hack to Release: Refleksi tentang Mencipta dan Mengeluarkan Projek Sumber Terbuka

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.

Kekalkan Skop

Memandangkan saya merancang untuk banyak bereksperimen dan saya benar-benar baru dalam Go, saya tahu saya akan melakukan banyak kerja tidak berstruktur.
Di sini adalah penting untuk menetapkan skop - bilakah ia cukup bagus untuk keluaran alfa?
Saya pada awalnya memutuskan fungsi yang sepatutnya ada, dan walaupun menggoda untuk duduk dan memperhalusi dan mengembangkannya lagi, ini bagus.
Saya boleh duduk dengan ini untuk masa yang lama.

Kesimpulan: Lepaskan projek sebagai alpha apabila anda sama-sama malu dan bangga dengannya.

Anggaran - Sejauh Mana Sukarnya?

Mempelajari bahasa baharu ialah sebahagian kecil daripada mempelajari bahasa itu sendiri, tetapi lebih banyak lagi tentang mempelajari ekosistem dan simpulan bahasanya.
Apakah perpustakaan yang digunakan, bagaimana ia digunakan, apakah cara idiomatik untuk melakukan ini dan itu?
Saya perlu menghabiskan banyak masa untuk belajar dan menyelidik semasa projek ini, mungkin 50% daripada masa saya akan
telah menghabiskan hanya pengekodan dalam bahasa dan ekosistem yang saya tahu.

Kesimpulan: Gandakan anggaran masa anda dengan tiga apabila mempelajari susunan teras baharu dan melibatkan percubaan. Sintaks bahasa akan menjadi perkara kecil.

Proses Penciptaan

Komitmen Awal

Pelaksanaan asas dilakukan dalam sehari - ia tidak mempunyai binaan, pengendalian ralat, dokumentasi, kes tepi, kebolehselenggaraan, dsb.
Di sinilah kebanyakan penggodaman pada hari Jumaat berakhir, dan kebanyakannya tidak pernah pergi lebih jauh.

Tetapi seperti yang diketahui oleh semua pembangun kanan, membuat sesuatu berfungsi adalah jauh daripada mengeluarkan produk.

Tak lama lagi, eh? Tidak juga.

Mencari Masa

Ada kalanya sukar mencari masa untuk meluangkan masa dengan projek itu, terutamanya kerana saya mempunyai musim bunga yang meletihkan di tempat kerja.
Bukan setiap malam anda berasa seperti membaca buku selama 2 jam tentang sesuatu yang khusus atau mempelajari teknologi baharu.
Atau menghabiskan masa menulis dokumentasi. Saya mempunyai anak dan rumah, dan saya tidak mampu untuk membiarkan projek persendirian memakan saya lebih daripada hobi lain.
Tetapi sesuatu sentiasa perlu diberikan - Saya akhirnya menonton lebih sedikit siri, dan sebarang permainan hampir tidak wujud dalam tempoh ini.

Dengan itu, walaupun saya berharap saya dapat meluangkan lebih banyak masa pada projek itu, ia hampir selalu memberi motivasi - Saya mempunyai beberapa sesi malam di mana saya kurang tidur dan berkod atau belajar,
kerana saya sangat teruja untuk pergi lebih jauh. Selain itu, apabila sesuatu yang menyeronokkan, ia menyeronokkan, sama ada mengangkat berat, menulis buku, mengembangkan diri, dsb.

Perkara yang Saya Lupa

Saya sudah terbiasa bekerja dalam pasukan sejak sekian lama. Dengan projek solo, anda perlu menguruskan lebih banyak topi dan menjadi agak baik dalam setiap bahagiannya, tidak selalunya teknikal.
Saya menghabiskan banyak masa untuk menggali reka bentuk CLI yang baik dan pilihan idiomatik. Bidang lain ialah proses pelepasan dan binari binari untuk platform yang berbeza.
Mengikuti SLSA dan piawaian lain dalam Sumber Terbuka juga mengambil masa. Dan kami mahukan liputan ujian yang baik, bukan?
Bekerja dalam satu pasukan, orang lain diharapkan dapat melakukan logo yang anda mahukan, dokumentasi yang perlu ditulis.
Bekerja solo, itu hanya anda atau ia tidak akan berlaku.
Menulis kod tidak sampai 50% daripada menyampaikan projek. Dan ada yang lain.

Sindrom Penipu Melanda

Sindrom Penipu adalah perkara biasa dalam dunia pembangun berasaskan pengetahuan kami. Setiap orang mempunyai kemahiran yang berbeza, dan pada bila-bila masa, akan sentiasa ada seseorang yang lebih tahu daripada anda.
Berada dalam satu pasukan, anda mempunyai seseorang untuk berbincang.
Sendiri, tidak sebanyak.

Tetapi, ini semua tentang menerima bahawa seseorang akan melakukan beberapa perkara bodoh dalam kod pada masa-masa tertentu.
Dan, Sumber Terbuka itu bukan tentang menjadi sempurna. Ini tentang belajar, menyelesaikan dan melepaskan perkara yang mungkin berguna kepada orang lain.

The Grind

Nah, apa yang boleh saya katakan - ia dilakukan apabila ia selesai.

Terdapat beberapa waktu penyahpepijatan lewat malam, pemfaktoran semula, tetapi juga detik aliran dan dopamin yang tidak terkira banyaknya.

Bagi saya, masa keluaran tiba apabila saya merasakan seni bina keseluruhan dalam projek tidak akan bergerak secara radikal - saya telah mengenal pasti antara muka dan merasakan ia boleh dilanjutkan.
Pangkalan kod OK.
Kebanyakan ciri asas ada dan sementara segala-galanya disediakan untuk penambahbaikan, ia masih menjadi asas untuk diusahakan.

Kesudahan dan Pengajaran

1. Tetapkan skop awal: Tentukan tempat untuk berhenti. Sediakan struktur projek, dokumentasi, keluaran, saluran paip dan garis panduan komuniti anda lebih awal. Masa depan anda akan berterima kasih kepada anda.

2. Jangan stress, nikmati proses pembelajaran: Ia dilakukan apabila ia selesai.

3. Tekun: Sumber terbuka ialah maraton, bukan pecut. Jangan burn out. Ia adalah hobi, bukan kehidupan anda. Namun tetap gigih. Lakukan perkara kecil setiap hari.

4. Apprendre, apprendre, apprendre : Voyez tout comme une opportunité d'apprendre et de vous améliorer, pas comme un problème.

5. 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à où on passe du temps.

6. 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.

7. 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.

8. 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.

9. Profitez du voyage :C'est merveilleux de créer.

10. Complétez-le : Il y a des millions de projets à moitié réalisés dans ce monde. Complétez-le.

11. 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.

Eh bien, bon hacking et maintenant, allez réfléchir à ce que vous voulez faire ensuite !!

Links

Le projet : Git Provider Sync

Atas ialah kandungan terperinci Dari Friday Hack to Release: Refleksi tentang Mencipta dan Mengeluarkan Projek Sumber Terbuka. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!