Como é um passo a passo para ler, interpretar, reproduzir e modificar um código de um projeto open source sem nunca ter trabalhado em um projeto anteriormente?

Sei que essa é uma pergunta parece algo óbvio para todos vocês.
Mas eu nunca tive a oportunidade de estagiar em algum projeto de software, seja ele livre, seja ele proprietário.
Eu olho esses códigos prontos, não sei nem por onde começar.
Estudo programação por alguns anos, mas mesmo assim sinto que a cada ano que fico sem trabalhar eu acabo perdendo parte da experiência e isso acaba virando uma bola de neve.
Se alguém dessa comunidade, pudesse dar uma ajuda, se eu pudesse pegar um projeto que eu me empolgue, poderia voltar até ao mercado de trabalho usando esse projeto como portifólio.

Bem, desculpe minha sinceridade, mas aqui fala um rapaz que está desempregado do ramo de programação desde 2015

3 curtidas

Hey, @Erikcht !

Eu não sou tão ativo assim na comunidade open-source, mas já tive uns poucos commits aprovados, e também trabalho com código fechado no meu trabalho. Primeiramente, acho uma ótima ideia! Tanto para treinar, quanto para experiência, inclusive acho que me ajudou a ser aprovado no meu atual emprego.

Sobre por onde começar, isso é uma crítica que eu tenho em relação a maioria dos projetos (não apenas open-source). A maioria não possuí um LeiaMe explicando como compilar, testar, debugar, … o que dificulta bastante o início. Então para mim essa é sempre a parte mais complicada. Mas tendo um pouco de paciência, investigar os arquivos do topo do projeto (ex.: Makefiles, run.sh, install.sh e scripts sh no geral, …) para tentar entender o processo de compilação e instalação, e acho que, principalmente, não ter medo de errar/quebrar o sistema, você com certeza vai conseguir sair do outro lado. E uma vez conseguindo passar por isso, entender e mexer no código passa a não ser tão complicado, porque você consegue colocar debugs, mudar valores de variáveis para verificar se está funcionando, … É claro que dependendo do projeto e problema que você escolher, isso será mais simples ou mais complicado. Vide o Kernel, por exemplo, ahahahaha

Já sobre o que fazer, ai acho que não tem outra resposta além de “depende”. Nas vezes que eu contribuí, foram pequenos problemas que me afetavam e então eu decidi tentar resolvê-los. Ex.: Os ícones do Mint não escalavam corretamente, quando estavam configurados com outra cor, e ficavam meio borrados justamente no tamanho que eu gostava de usar.. Basicamente o que eu fiz foi procurar pelo projeto que fazia essa função no Github do Mint, ai descobri que era em Python, uma linguagem que eu consigo entender/escrever, rodei o Makefile até conseguir compilar/instalar (precisou instalar várias libs extras), e ai fui conseguindo corrigir o problema.

Porém, caso não tenha nada que te incomode, ou que deseja ajustar, sempre existem as listas de bugs nos projetos. No Github aparece na aba “Issues”. Ex.: Issues · linuxmint/folder-color-switcher · GitHub Ai é uma questão de você procurar por um projeto que você goste ou que use uma linguagem que você domine e um bug que não pareça tão complicado, e trabalhar nele. A minha sugestão é pegar bugs que não sejam o “core” da aplicação, e sim algum botão que tá errado, um ícone, algo mais “superficial”.

Dando uma dica, a minha última contribuição está sendo (porque ainda não foi aprovada) um ajuste em uma extensão do Mint: Add "Notifications disabled" icon clue to Inhibit Applet by BrunoNZ · Pull Request #11228 · linuxmint/cinnamon · GitHub
Elas são todas escritas em Javascript - o que pro bem ou pro mal, está em tudo que está em tudo que é lugar, incluindo projetos closed-source - e são fáceis de instalar (só duplicar o diretório da extensão, mudar o nome e infos no arquivo de definições, e mover para o diretório ${HOME}/.local/share/cinnamon/applets/, o que vai fazer aparecer uma nova opção na lista de extensões, que você pode adicionar no seu menu e começar a trabalhar). Para testar, basta usar o atalho “Ctrl + Alt + Esc” para reiniciar o Cinnamon, e ai as modificações que você fez serão aplicadas. Então o processo de tentativa/erro fica bem rápida. Obviamente você precisará usar o Cinnamon, o que também fica como uma dica! ahahaha
Com isso você tem várias opções, como tentar melhorar/ajustar alguma extensão já existente, pode criar uma com base em algum modelo para ser adicionada em Cinnamon-Spices ou até pegar uma dessa lista de Spices para ajustar/melhorar.
A parte boa é que normalmente o código delas estão em alguns alguns poucos arquivos relativamente simples, então é mais fácil de encontrar a parte onde está o problema.

4 curtidas

As dicas do @brunonzanette já são ótimas. Outra dica é ir dar uma conversada nos canais de comunicação dos desenvolvedores. Só tente não tomar muito tempo do pessoal por lá, procure ser objetivo.

Se você não souber bem ao certo o que quer fazer, pode perguntar se eles têm algumas tarefas para juniores. Frequentemente, projetos Open estão envolvidos em algumas iniciativas como Google summer of code e afins, e também costumam ter várias tarefas menores que podem ser boas para iniciantes no projeto.

2 curtidas

Normalmente o iniciante se debruça sobre os pequenos detalhes. Quase todos os projetos opensource precisam de pequenos ajustes na estética, na tradução, na indentação do código e por aí vai.

A gente começa aos poucos em pequenas coisas, quando menos se espera estamos envolvidos em “encrencas” maiores dos códigos.

3 curtidas

@Natanael.755 tem dicas?

Ótimo texto!

2 curtidas

Não é muito difícil se você tiver a base (linguagem/toolkits usados), além das dicas que o @brunonzanette colocou, aqui vai mais algumas:

  1. Escolha algum projeto sem dono, eles são mais fáceis de começar, praticamente todos os do KDE não tem (por favor não confunda ter dono com ter mantenedor), basicamente esses projetos você não vai precisar pedir permissão pra contribuir, você clona o repositório e abre um pedido de mesclagem simplesmente assim sem pedir permissão, sem ter que discutir (embora explicar o que você fez e porque fez na mensagem de commit seja essencial)

  2. Leia as issues, geralmente quando bem feitas e se o projeto for bem organizado você vai saber exatamente o(s) arquivo(s) que tem que mecher

  3. Lembre-se de seguir o estilo de código do projeto mesmo que você ache zoado usar 8 espaços para indentar você vai ter que usar 8 espaços pra indentar se isso fizer parte do estilo do projeto

Geralmente é isso, conhecimento ainda que básico na linguagem e framework do projeto é essencial, conhecimento de git é o mínimo você não vai conseguir sem saber git

4 curtidas