5 dicas para escolher o código-fonte aberto certo

Estudos conduzidos pelo Google mostram que, para muitos desenvolvedores, encontrar código online consome uma grande parte do dia. Encontrar uma função simples, uma biblioteca, um pacote útil, um componente reutilizável ou um tutorial de blog "como fazer" útil nem sempre é simples. Saber se você pode confiar e usar o código que encontrou pode ser ainda mais complicado.

Encontrar o código certo geralmente significa recorrer aos deuses do Google ou de outros mecanismos de pesquisa, fazer uma consulta e cruzar os dedos para uma vitória rápida. Consultas funcionais simples, como “Javascript possui propriedade própria”, provavelmente levarão a diferentes fóruns e postagens de blog, enquanto descrições de nível superior (“Componente React x”) geralmente levam você ao GitHub ou NPM.

No entanto, mesmo depois de encontrar o código certo - confiar e usá-lo é um problema totalmente diferente. Para ajudar a entender qual código você pode realmente usar, reuni 5 parâmetros que podem ser úteis para considerar. Tomar a decisão certa deve levar em consideração esses parâmetros (entre outros), bem como a natureza da tarefa em si. Aqui estão as 5 chaves que você pode considerar para escolher o código certo.

# 1. O código é legível?

Código legível significa muito mais do que apenas bons comentários e documentação. Isso significa que o próprio código deve ser legível para você. Parâmetros diferentes para legibilidade podem ser boas convenções de nomenclatura para identificadores, bom espaçamento, lógica legível clara, escopos bem compreendidos e muito mais. O resultado final é que o código deve ser legível para você . Quando você escolhe um trecho de código, mesmo um que funcione, mas você não entende totalmente como funciona - você está basicamente trazendo uma bomba-relógio de manutenção em sua base de código.

Depurar, modificar, atualizar e manter o código que você não consegue ler é algo que você deve evitar fortemente. A melhor maneira de evitá-lo é nunca deixá-lo em primeiro lugar, quando possível.

# 2. O código é mantido ativamente?

Queremos que o código que escolhemos esteja “vivo”. Ou seja, queremos saber os bugs, problemas e atualizações estão sendo tratados e este código será mantido ativamente pelos desenvolvedores que o escreveram. Um bom exemplo para um indicador de atividade pode ser os problemas abertos do GitHub, solicitações de pull e indicador de pulso. Os gerenciadores de pacotes fornecem informações relevantes para manutenção, como o número de dependências e projetos dependentes, mas ainda assim, lutam para apresentar uma métrica confiável neste campo.

Ainda assim, se um grande projeto popular depende de outro pacote, podemos presumir que os problemas têm uma grande probabilidade de serem corrigidos (no entanto, todos nos lembramos do botão esquerdo). No entanto, ao copiar o código do estouro de pilha (o que é um problema por si só), você não tem como saber que pode confiar que esse código será mantido, a não ser atualizá-lo você mesmo sempre que necessário (e onde quer que você o tenha duplicado).

Funcionalidades básicas pequenas simplesmente não mudam tanto. Nesse espírito, os componentes reutilizáveis ​​importados do Bit contam com um controle de versão incremental simples que aumenta a versão do componente em 1 cada vez que seu autor muda algo. Manter seus componentes em uma versão “atualizada mais recentemente” significa que, dados bons testes, seu código pode ser mantido ativamente por seu mantenedor enquanto ainda atualiza até mesmo pequenas funções ou componentes em seu código sem quebrar nada.

# 3. O código foi bem testado?

Escolher um código que funcione é provavelmente nossa primeira prioridade. Os testes são uma ótima maneira de saber se o código que uso realmente faz o que deveria fazer. A descrição dos testes também apresenta diferentes casos de uso e casos extremos que nos ajudam a saber como esse código se comportará em diferentes situações. O uso de componentes testados torna o software mais sustentável como um todo, economizando tempo e problemas ao tentar mudar coisas antes de ir para a produção.

Snippets copiados de toda a web geralmente não vêm com testes. Raramente, se alguma, as funções copiadas de fóruns ou postagens de blog incluirão testes de unidade. Pacotes e bibliotecas podem muito bem ser testados, o problema está em ser capaz de descobrir isso rapidamente. Ao explorar uma biblioteca no GitHub, diferentes selos ou arquivos no repositório podem indicar quão bem e quanto desse código foi testado. Ainda teremos que usar indicadores fornecidos por ferramentas externas para descobrir se os testes foram aprovados ou não. Ao procurar por um pacote, não há realmente uma maneira confiável de saber qual pacote foi testado e se os testes foram aprovados de forma útil. Este é um grande problema quando se trata de descoberta de pacotes. Reutilizável

Ao procurar um pacote, não há realmente uma maneira confiável de saber qual pacote foi testado e se os testes foram aprovados de forma útil. Este é um grande problema quando se trata de descoberta de pacotes. Os componentes de bits reutilizáveis ​​podem ser testados se tais testes forem adicionados pelo desenvolvedor. O Bit Scope executa o teste de forma que os indicadores verdes e a descrição dos testes possam ser mostrados online antes de escolher um componente do hub da comunidade Bit (ou via CLI quando usado em sua máquina local de maneira distribuída).

# 4. O código está sendo usado por outras pessoas?

Popularidade é algo em que os evolucionários confiam. A opinião pública é boa para tomar decisões que ajudam a nossa sobrevivência. Se virmos todos comendo uma determinada fruta de uma árvore, sabemos que provavelmente não nos matará. Se virmos todos fugindo dos arbustos, um tigre faminto pode vir em breve. Até certo ponto, o mesmo se aplica à escolha do código em 2017.

Em torno dos fóruns de programação, podemos usar diferentes indicações, como um “V” marcando as respostas corretas, o número de votos positivos e as opiniões vocais dos usuários. Esses são recursos excelentes e reconfortantes para aumentar a probabilidade de o código funcionar bem. Quando se trata do GitHub, podemos contar com estrelas, colaboradores e outras métricas sociais para obter um sentimento de confiança. Ao procurar por pacotes, um bom indicador seria o número de downloads deste pacote.

Os componentes de bits encontrados no hub da comunidade de bits apresentam o número de downloads, colaboradores (no nível de escopo), “curtidas” simples e mais (conforme mostrado neste Escopo de componentes React). De qualquer forma, tenha em mente que as métricas sociais são uma boa indicação - mas uma verdade absoluta sobre a qualidade do código. Muitas vezes as pessoas estão erradas e a opinião pública pode mudar mais rápido do que pensamos.

# 5. O código está bem documentado?

A documentação torna o código muito mais fácil de entender, usar e modificar. Também é uma ótima indicação para a reflexão e cuidado que o desenvolvedor que escreveu o código colocou nele. A documentação do código encontrado no Stack Overflow ou em diferentes postagens de blog pode consistir em comentários no próprio código, bem como na resposta real ou blog em que foi encontrado. Quando uma resposta de fórum inclui uma elaboração útil sobre o código que inclui, isso pode muito bem ser uma documentação que vale a pena adicionar, mesmo ao copiar e colar o próprio código (novamente, não copie e cole o código).

Para repositórios e pacotes do GitHub, as coisas são um pouco mais complicadas. Normalmente, os arquivos leia-me e docs apresentados no GitHub ou NPM fornecerão uma indicação geral quanto à qualidade da documentação. A documentação dos componentes Bit é analisada de dentro do próprio código e, portanto, mostra a descrição real do componente atômico e também pode incluir exemplos de uso e uma assinatura especificada, incluindo argumentos e retornos para diferentes funções e comportamento para componentes React e outros. De qualquer forma, escolher o código documentado é uma boa decisão sempre que possível.

Para repositórios e pacotes do GitHub, as coisas são um pouco mais complicadas. Normalmente, os arquivos leia-me e docs apresentados no GitHub ou NPM fornecerão uma indicação geral quanto à qualidade da documentação. A documentação dos componentes Bit é analisada de dentro do próprio código e, portanto, mostra a descrição real do componente atômico e também pode incluir exemplos de uso e uma assinatura especificada, incluindo argumentos e retornos para diferentes funções e comportamento para componentes React e outros. De qualquer forma, escolher o código documentado é uma boa decisão sempre que possível.

Tomando a decisão

No final das contas, a memória humana é limitada e realmente não há muito sentido em reinventar a roda todas as vezes. No entanto, ao localizar e usar um trecho de código-fonte aberto, os indicadores acima podem ajudar a garantir que seu aplicativo permaneça seguro, sustentável, funcionando e com boa saúde.

Diferentes casos de uso significam atribuir pesos diferentes aos diferentes parâmetros. Ao escolher um pacote, será difícil saber o quão testado, legível, documentado e mantido ativamente. Ao copiar o código de um fórum online, podemos priorizar a popularidade em relação aos testes, manutenção e assim por diante. Os componentes de bits combinam informações relevantes para importar e reutilizar componentes e funcionalidades atômicas, como descrição, exemplos, downloads, dependências, descrição de testes, resultados de testes e muito mais. Ao considerar cuidadosamente esses diferentes parâmetros, podemos tomar uma decisão informada e cruzar o labirinto de encontrar e escolher o código certo para o trabalho.