Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cultura Open Source no ambiente de trabalho (pt.01)

F803c45d62a468e0cb990398c004bd3e?s=47 Vinicius Reis
February 24, 2021

Cultura Open Source no ambiente de trabalho (pt.01)

Entendemos como cultura open source um conjunto de comportamentos e formas de como o código/software é gerenciado.

F803c45d62a468e0cb990398c004bd3e?s=128

Vinicius Reis

February 24, 2021
Tweet

Transcript

  1. Cultura Open Source no ambiente de trabalho

  2. Cultura Open Source no ambiente de trabalho (parte 1)

  3. Vinicius Reis @vinicius73 @LuizVinicius73 Escrevo artigos sobre Vue.js e JavaScript.

    vinicius73.dev Plataformas Thundercats @ M4U @vinicius73
  4. O que é Open Source?

  5. O que é Open Source? - Qualquer um pode usar

    - Qualquer um pode ver - Qualquer um pode modificar - Qualquer um pode distribuir
  6. O que é Open Source Código Aberto? - Qualquer um

    pode usar - Qualquer um pode ver - Qualquer um pode modificar - Qualquer um pode distribuir
  7. Código Aberto e Código Livre não são a mesma coisa!

    (Apesar de estarem muito ligados)
  8. Licenças!! As licenças atreladas ao código e software determinam como

    devemos classificar ele. Por isso, mas não exclusivamente, devemos sempre configurar adequadamente a licença do software, mesmo ele não sendo “aberto”; (O mesmo vale para as dependências das nossas aplicações, fiquem atentos!)
  9. Afinal o que é uma cultura open source?

  10. “conjunto de padrões de comportamento, crenças, conhecimentos, costumes etc. que

    distinguem um grupo social.” Entendemos como cultura open source um conjunto de comportamentos e formas de como o código/software é gerenciado.
  11. Cultura Open Source dentro de uma empresa; - Qualquer pessoa

    ou time tem acesso ao código; - Qualquer pessoa ou time pode submeter mudanças;
  12. Então, basta abrir o código?

  13. Não!!

  14. Cultura Open Source dentro de uma empresa; - Qualquer pessoa

    ou time tem acesso ao código; - Saber como o código funciona; - Saber como executar o código; - Saber como testar o código; - Qualquer pessoa ou time pode submeter mudanças;
  15. Transparência & Publicidade

  16. Documentação ato, processo ou efeito de documentar.

  17. Documentar nem sempre é uma tarefa fácil. É necessário dedicação

    para não apenas manter a documentação atualizada, como também encontrar formas de dar clareza sobre tudo relacionado ao projeto. Documentação
  18. Documentação > Objetivo Por quê este projeto existe? Todo e

    qualquer projeto precisa de uma motivação para existir e continuar a ser mantido. Essa motivação precisa ser clara e evidente para qualquer um que tiver contato com o código. Como o projeto resolve o problema? Uma descrição clara de qual é a abordagem do projeto facilita o entendimento do próprio código. aquilo que se pretende alcançar quando se realiza uma ação; propósito.
  19. Documentação > Stack Qual a stack do projeto? Uma descrição

    ou lista de quais são as tecnologias usadas no projeto ajuda a entender rapidamente quais as dependências do mesmo e o necessário para ele funcionar. De sistemas de fila a bancos de dados para cache ou dados persistentes, além de referências para libs ou frameworks usados no projeto. Toda informação agrega no aprendizado do próprio projeto. conjunto de tecnologias usadas no projeto
  20. Documentação > Infra/Arquitetura Esquema de funcionamento Fluxo da informação Não

    é raro ficar sem entender por onde a informação chega, o que é feito com ela e para onde ela vai. Um desenho explicando isso poupa várias horas de qualquer profissional que está começando no projeto ou voltando para ele. conjunto de elementos que perfazem um todo; estrutura, natureza, organização.
  21. Documentação > Relacionamentos Com quais outros projetos este projeto se

    relaciona? Uma breve lista de links de projetos relacionados. Podem ser projetos de qualquer natureza, dependências diretas ou indiretas. Projetos que dependem do projeto atual ou projetos que ele depende. Esse tipo de informação economiza horas de trabalho. capacidade de manter relacionamentos, de conviver bem com seus semelhantes.
  22. Documentação > Fluxo de trabalho Como fazemos para o projeto

    “rodar”? Não devemos nunca assumir que quem for trabalhar no projeto conhece determinados comandos ou usa determinadas IDEs, muito menos que conhece a stack do projeto. Uma coleção de comandos simples e úteis para o desenvolvimento do projeto. De testes a build, quanto mais comandos documentados melhor. sequência de passos necessários para automatizar processos
  23. Documentação > Configuração Quais as opções deste projeto? Quais as

    variáveis de ambiente? Há arquivos de configuração? Procuramos sempre criar projetos que não dependam de mudanças no código para que comportamento ou ações também mudem. Para isso existem as configurações. Uma lista delas ou um link para o arquivo onde elas ficam (devidamente comentadas e descritas), ajuda a fácilmente entender boa parte das possibilidades do projeto. ato ou efeito de configurar.
  24. Documentação > API Quais os endpoints e contratos do projeto?

    Sejam APis Rest, consumidores ou produtores de eventos, todo projeto possui uma coleção de “contratos”. Há inúmeras formas de se documentar isso. Não importa se a documentação é automática, viva ou estática, ela precisa existir. A documentação da API pode estar no README do projeto ou fora dele, quando for este o caso, novamente, faça referência disso no README do projeto. acordo entre as partes, que se obrigam a cumprir o que foi combinado sob determinadas condições
  25. “O conjunto da obra que faz a diferença” Comece simples,

    comece pelo básico e vá melhorando aos poucos.
  26. “Não monopolize a informação” Passagens de conhecimento são muito mais

    simples com uma documentação de apoio.
  27. “Valorize a documentação tanto quanto os testes da aplicação” Devemos

    tratar a documentação como algo tão vital quanto os testes automatizados.
  28. Acesso Informação Liberdade Evolução

  29. Momento Motivacional!

  30. Todos amam uma boa documentação. Muitas vezes escolhem algo justamente

    pela documentação.
  31. Abrace uma documentação. Você pode precisar dela um dia.

  32. Documentações não nascem sozinhas. Cada informação conta.

  33. Sua equipe precisa de você, documente seus projetos!

  34. Toda documentação precisa ser cuidada. Salve um projeto, documente, crie

    um README legal...
  35. Você consegue, documente!

  36. Documentações salvam vidas. Não crie seu projeto sem elas.

  37. Obrigado

  38. None