Do Patch Hack de sexta-feira ao lançamento: Reflexões sobre a criação e o lançamento de um projeto de código aberto

Isso faz parte de uma série voltada para desenvolvedores iniciantes e intermediários, divulgando ou intrigados por divulgar suas ideias como Projetos Open Source.
Essas reflexões são tendenciosas e pessoais. Mais artigos estão planejados. Ao compartilhar algumas reflexões, espero inspirar você a fazer seus próprios projetos

• Reflexões (isto)
• Aprendendo Go lang como desenvolvedor Java (TODO)
• Arquivos de saúde e comunidade de código aberto (TODO)
• Segurança de código aberto (TODO)

As necessidades

Tudo começou há anos. De vez em quando, eu precisava de algo que sempre envolvesse a recriação do mesmo script Bash antigo, por mim ou por outra pessoa.
Os requisitos gerais eram simples, pois muitas vezes são de alto nível.
O que nós, desenvolvedores, fazemos principalmente é apenas embaralhar informações do ponto A ao ponto B, certo?

Aqui, o objetivo era espelhar vários repositórios Git - para outro provedor Git, para disco, para um formato de arquivo, em um aplicativo CLI.
Eu precisava disso em particular e em minha função profissional. Já vi pessoas lutando, investindo muito tempo fazendo essas coisas manualmente, e isso me incomoda.

Mesmo assim, sempre pareceu permanecer como um simples script Bash. Feito rapidamente, mas assim que algo extra teve que ser adicionado - casos especiais, tratamento de erros, modularização, empacotamento, etc. - Os scripts Bash não suportam ferramentas maiores, como a maioria de nós concordaria.

Então decidi criar um aplicativo CLI completo para ele.

As pré-decisões a serem tomadas

Essa ferramenta já existe?

A primeira coisa a fazer foi não reinventar a roda.
Existem algumas ferramentas de código aberto que resolvem esse problema. Pelo menos um escrito em Go, alguns scripts Bash e, se contar, funções de importação como a do Gitea.
Eu os experimentei, mas não consegui encontrar nenhum que funcionasse totalmente do jeito que eu queria. E como eu tinha outras ideias de onde queria levar o projeto, decidi não me aprofundar
começando a aplicar patches nos projetos existentes.

Também existem algumas ferramentas comerciais, mas achei que essa ferramenta pequena é algo que também deveria existir em formulários de código aberto.

Conclusão: Havia um lugar para esta ferramenta CLI neste mundo.

Hackear isso em dias de trabalho ou em tempo livre privado?

Temos tempo de hacking no trabalho no final dos sprints e em outras ocasiões. Uma abordagem seria hackeá-lo nessas ocasiões ao longo do tempo, transformando-o em algo útil.
Rapidamente decidi fazê-lo integralmente em meu tempo livre, pelos seguintes motivos:

• As oportunidades de hack no trabalho devem ser usadas para breves momentos de aprendizado e criatividade, e não para a elaboração de um projeto completo a longo prazo.
• A solução não se enquadra nos negócios da organização principal - nesse caso, seria sempre um problema estranho.
• Amarrá-lo ao trabalho faria com que parecesse apenas mais trabalho - estou fazendo isso para me divertir e aprender Go etc - isso colocaria pressão e estresse em mim.
• Fazer isso nos dias de trabalho levaria uma eternidade. Algumas horas, distribuídas por semanas.

Conclusão: Eu deveria fazer isso para me divertir no meu tempo livre.

Escolha da pilha de tecnologia

Passei a maior parte do meu tempo ao longo dos anos no mundo Java/Kotlin, com alguns projetos em JS/TS, Python/Ruby e, como todo desenvolvedor sênior, às vezes me interessando por outros.
Há muito tempo, porém, eu queria realmente aprender Go e/ou Rust. Então esta seria uma oportunidade de obter motivação para mergulhar em um novo idioma
A razão pela qual escolhi Go é que alguns aplicativos CLI no mundo DevOps de código aberto estão escritos nele, e às vezes quero poder enviar patches para projetos de terceiros. Além disso, escrever em Go significa um binário com muitas arquiteturas de destino.

Eu poderia ter feito isso em Java, por exemplo, com Pico CLI e GraalVM, dos quais tive uma boa impressão desde as tentativas anteriores, mas decidi que realmente queria aprender Go.

Conclusão: Eu deveria fazer isso em Vá e aprender com isso.

Outras metas de aprendizagem

Com isso, eu também queria me aprofundar nos assuntos de entrega de um projeto Open Source bem embalado, seguindo a maioria das práticas de segurança - scorecards, SLSA,

e usando ferramentas como GoRelease para criar compilações de vários tipos.

Conclusão: Aproveite para aprender e se aprofundar nos temas de sua preferência.

Mantenha o escopo

Como eu planejava experimentar muito e era totalmente novo no Go, sabia que faria muito trabalho não estruturado.
Aqui foi importante definir o escopo - quando seria bom o suficiente para uma versão alfa?
Eu decidi desde o início quais funcionalidades ele deveria ter e, por mais tentador que fosse sentar, refiná-lo e expandi-lo ainda mais, isso foi bom.
Eu poderia ficar sentado com isso por muito tempo.

Conclusão: Lance o projeto como alfa quando você estiver igualmente envergonhado e orgulhoso dele.

Estimativa - quão difícil pode ser?

Aprender um novo idioma é uma pequena parte do aprendizado do idioma em si, mas muito mais sobre aprender o ecossistema e seus idiomas.
Quais bibliotecas são usadas, como são usadas, quais são as formas idiomáticas de fazer isso e aquilo?
Eu teria que gastar muito tempo aprendendo e pesquisando durante este projeto, talvez 50% do tempo que eu faria
gastei apenas codificando em uma linguagem e ecossistema que conheço.

Conclusão: Multiplique sua estimativa de tempo por três ao aprender novas pilhas principais e envolver experimentação. A sintaxe da linguagem será a pequena coisa.

O Processo de Criação

Compromisso inicial

A implementação básica foi feita em um dia - não teve compilações, tratamento de erros, documentação, casos extremos, capacidade de manutenção, etc.
É aqui que a maioria dos hacks de sexta-feira termina, e a maioria deles nunca vai além.

Mas, como todos os desenvolvedores seniores sabem, fazer algo funcionar está a muitos quilômetros do lançamento de um produto.

Pronto, né? Na verdade.

Encontrando o tempo

Às vezes era muito difícil encontrar tempo para dedicar ao projeto, especialmente porque tive uma primavera exaustiva no trabalho.
Não é toda noite que você tem vontade de ler um livro por 2 horas sobre algo específico ou aprender uma nova tecnologia.
Ou gastando tempo escrevendo documentação. Tenho filhos e uma casa, e não poderia permitir que um projeto privado me consumisse mais do que outros hobbies.
Mas algo sempre tem que acontecer - acabei assistindo menos séries e qualquer jogo foi quase inexistente durante esse período.

Dito isso, embora eu desejasse poder passar mais tempo no projeto, quase sempre foi motivador - tive algumas sessões noturnas em que dormi menos e codifiquei ou estudei,
porque eu estava muito animado para ir mais longe. Além disso, quando algo é divertido, é divertido, seja levantar pesos, escrever um livro, desenvolver, etc.

As coisas que esqueci

Há muito tempo que estou acostumado a trabalhar em equipe. Com um projeto solo, você tem que gerenciar muito mais chapéus e ser muito bom em todas as partes deles, nem sempre técnico.
Passei muito tempo pesquisando um bom design de CLI e escolhas idiomáticas. Outra área foi o processo de lançamento e construção de binários para diferentes plataformas.
Seguir o SLSA e outros padrões de código aberto também levou tempo. E queremos uma boa cobertura de testes, certo?
Trabalhando em equipe, esperamos que outra pessoa faça o logotipo que você deseja, a documentação necessária para ser escrita.
Trabalhando sozinho, é só você ou isso não acontecerá.
Escrever código não representa nem 50% da entrega de um projeto. E tem o resto.

A síndrome do impostor ataca

A Síndrome do Impostor é comum em nosso mundo de desenvolvedores baseado em conhecimento. Cada pessoa tem habilidades diferentes e, a qualquer momento, sempre haverá alguém que sabe mais do que você.
Estando em equipe, você tem alguém com quem discutir as coisas.
Sozinho, não tanto.

Mas, trata-se de aceitar que às vezes alguém fará algumas coisas estúpidas no código.
E esse código aberto não significa ser perfeito. Trata-se de aprender, resolver e liberar coisas que podem ser úteis para outras pessoas.

A moagem

Bem, o que posso dizer - estará feito quando estiver feito.

Houve algumas noites de depuração e refatoração, mas também incontáveis ​​momentos de fluxo e dopamina.

Para mim, o momento do lançamento chegou quando senti que a arquitetura geral do projeto não mudaria radicalmente - identifiquei as interfaces e senti que isso seria extensível.
A base de código está OK.
A maioria dos recursos básicos está lá e, embora tudo precise de melhorias, ainda é uma base para trabalhar.

As consequências e as lições aprendidas

1. Defina o escopo antecipadamente: Decida onde parar. Configure antecipadamente a estrutura, a documentação, os lançamentos, os pipelines e as diretrizes da comunidade do seu projeto. No futuro você agradecerá ao passado.

2. Não se estresse, aproveite o processo de aprendizagem: Está feito quando estiver feito.

3. Seja persistente: O código aberto é uma maratona, não um sprint. Não se queime. É um hobby, não sua vida. No entanto, seja persistente. Faça uma pequena coisa todos os dias.

4. Aprenda, aprenda, aprenda: Veja tudo como uma oportunidade de aprender e melhorar, não como um problema.

5. Codificar é a parte fácil: O código principal é o que levará menos tempo; todo o resto, como documentação, testes, etc., é onde o tempo é gasto.

6. Faça os extras: Eles são tão divertidos quanto programar. Sim, até mesmo a documentação pode economizar horas de explicações e reexplicações. Torne isso divertido se você estiver entediado. Documentos como código, vim-pong, etc.

7. Faça pausas: O esgotamento é real. Dê um passo para trás quando precisar. Assim como qualquer outro processo de aprendizagem criativa, faça-o em lotes.

8. Use o sistema: Use seu próprio dogfood na prática e no mundo real o mais cedo possível. Melhor ainda, encontre uma pessoa/comunidade para dar feedback.

9. Aproveite a jornada: É maravilhoso criar.

10. Conclua: Existem zilhões de projetos pela metade neste mundo. Conclua.

11. Use IA como ajuda: Eu economizo horas delegando alguns extras a ela, como pedir melhorias de código, revisões de código, estruturas de documentos, resumos, etc. sempre confie cegamente. Revise e critique as respostas.

Bem, feliz hacking e agora pense no que você quer fazer a seguir!!

Ligações

O projeto: Sincronização do provedor Git