6 lições que aprendi desenvolvendo projetos de código aberto

A perspectiva de um cientista de dados

Código aberto é um conceito incrível! Ao reunir as fontes, as competências e o conhecimento de toda uma comunidade, podem ser criadas ferramentas que não poderíamos ter criado isoladamente. As ferramentas que resultam destas colaborações são verdadeiramente mais do que a soma das suas partes.

Como resultado, nós, cientistas de dados, usamos este software disponível gratuitamente que impulsiona tantas tecnologias, ao mesmo tempo que temos a oportunidade de estar envolvidos no seu desenvolvimento.

Nos últimos anos, tive a sorte de estar envolvido com código aberto e tive a oportunidade de desenvolver e administrar diversos pacotes!

Desenvolver código aberto é mais do que apenas codificar

Durante esse período, houve muitos obstáculos a serem superados e lições a serem aprendidas. Desde dependências complicadas e opções de design de API até comunicação com a base de usuários.

Trabalhar em código aberto, seja como autor, mantenedor ou desenvolvedor, pode ser bastante assustador! Com este artigo, compartilho algumas de minhas experiências neste campo que espero ajudar aqueles que desejam desenvolver código aberto.

Ao criar software de código aberto, normalmente você não cria o pacote exclusivamente para você. Usuários de todos os tipos e origens diferentes farão uso do seu software. A documentação adequada ajuda muito esses usuários a começar.

No entanto, não subestime o impacto que a documentação pode ter na usabilidade do seu pacote! Você pode usá-lo para explicar algoritmos complexos, fornecer tutoriais extensos, mostrar casos de uso e até mesmo permitir exemplos interativos.

Especialmente software relacionado à ciência de dados pode ser difícil de entender quando envolve algoritmos complexos. Abordar essas explicações como uma história muitas vezes me ajudou a torná-las mais intuitivas.

Acredite em mim, escrever uma boa documentação é uma habilidade em si.

Outro benefício é que escrever documentação sólida reduz o tempo gasto em questões. Há menos motivos para os usuários fazerem perguntas se puderem encontrar as respostas na sua documentação.

No entanto, criar documentação é mais do que apenas escrevê-la. Visualizar seu algoritmo ou software ajuda muito a torná-lo intuitivo. Você pode aprender bastante com Jay Alammar quando você deseja visualizar princípios algorítmicos em sua documentação. Suas visualizações acabaram até no site oficial Numpy documentação!

Sua base de usuários, a comunidade, é um componente importante do seu software. Como estamos desenvolvendo código aberto, é seguro dizer que queremos que eles estejam envolvidos no desenvolvimento.

Ao se envolver com a comunidade, você os incentiva a compartilhar problemas e bugs, mas também a solicitar recursos e ótimas ideias para desenvolvimento futuro! Tudo isso ajuda a criar algo para eles.

A comunidade de código aberto é realmente mais do que a soma de suas partes

Muitos recursos principais do BERTopic, como modelagem de tópicos on-line, foram implementados por serem muito solicitados por seus usuários. Como resultado, a comunidade é bastante ativa e tem ajudado muito na detecção de problemas e no desenvolvimento de novos recursos.

Quer seu pacote seja usado milhões de vezes ou apenas algumas, criar um é uma excelente oportunidade para aprender mais sobre código aberto, MLOps, testes unitários, design de API, etc. do que eu teria no meu trabalho diário.

Há também uma enorme oportunidade de aprendizagem na interação com a própria comunidade. São eles que dizem quais designs gostam ou não. Às vezes, vi o mesmo problema surgindo várias vezes ao longo de alguns meses. Isso indica que eu deveria repensar o design, pois não era tão fácil de usar quanto eu esperava!

Além disso, o desenvolvimento de projetos de código aberto me deu a oportunidade de colaborar com outros desenvolvedores.

Trabalhar em seus próprios projetos de código aberto fora do trabalho traz suas desvantagens. Para mim, o mais significativo é que manter o pacote, responder a perguntas e participar nas discussões pode dar bastante trabalho.

Definitivamente ajuda se você estiver intrinsecamente motivado, mas ainda leva algum tempo para garantir que tudo esteja bem.

Felizmente, você pode recorrer à sua comunidade para ajudá-lo ao responder perguntas, apresentar casos de uso, etc.

Ao longo dos últimos anos, aprendi a ficar um pouco mais relaxado quando se trata de mudanças radicais. Especialmente quando se trata de dependências, às vezes há tanta coisa que você pode fazer!

Saber com que frequência seu pacote é usado é uma grande ajuda para entender o quão popular ele é. No entanto, muitos ainda usam estrelas do Github para equiparar um pacote a qualidade e popularidade.

Como cientistas de dados, devemos primeiro entender o que estamos medindo exatamente. As estrelas do GitHub nada mais são do que um usuário atribuindo uma estrela a um pacote. Isso nem significa que eles usaram o software ou que ele está realmente funcionando!

Tecnicamente, posso pagar mil pessoas para marcar meus repositórios com estrela. Em vez disso, concentro-me em uma variedade de estatísticas, como downloads e forks, mas também no número de problemas que recebo diariamente.

Por exemplo, é ótimo se seus pacotes forem apresentados em Hacker News mas não informa se é usado de forma consistente.

Como psicóloga, costumo me concentrar muito no design das minhas embalagens. Isso inclui coisas como documentação e tutoriais, mas também se traduz em como eu codifico.

Garantir que o pacote seja fácil de usar e instalar torna a adoção muito mais simples. Especialmente quando você se concentra em filosofias de design como modularidade e transparência, alguns pacotes tornam-se incríveis de usar.

Adotar a perspectiva de um psicólogo ao desenvolver novos recursos tornou muito mais fácil saber no que focar. O que os usuários procuram? Como posso codificar de uma forma que explique o algoritmo? Por que os usuários estão realmente usando este pacote? Quais são as principais desvantagens do meu código?

Dedicar um tempo para entender o usuário médio impulsiona a adoção

Todos os itens acima geralmente levam a uma regra básica, mas importante;
Mantenha tudo super simples

Pessoalmente, se eu achar um novo pacote difícil de instalar e usar, é menos provável que eu o adote em meu fluxo de trabalho.

Se você é, como eu, apaixonado por IA, Ciência de Dados ou Psicologia, sinta-se à vontade para me adicionar no LinkedIn ou siga-me no Twitter. Você também pode encontrar parte do meu conteúdo no meu Site pessoal.

Todas as imagens sem crédito de origem foram criadas pelo autor

6 lições que aprendi com o desenvolvimento de projetos de código aberto republicados da fonte https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 via https://towardsdatascience.com/feed

<!–

->