[FEAT] - Implementar ferramenta de Code Review | Codacy

[emerson-oliveira]

Contexto

Para melhorar a qualidade do nosso código e facilitar o processo de revisão de código, precisamos de uma ferramenta de code review automatizada. A Codacy é uma opção que oferece essa funcionalidade e traz várias vantagens para projetos de código aberto:

1. Padrão de qualidade de código: A Codacy pode ajudar a impor seu padrão de qualidade de código.
2. Economia de tempo em revisões de código: A Codacy pode economizar tempo nas revisões de código, permitindo que os revisores se concentrem em aspectos mais complexos do código.
3. Melhores práticas de segurança: A Codacy pode ajudar a aplicar as melhores práticas de segurança no seu código.
4. Integração com Git: Ao se integrar com seu provedor Git, a Codacy mantém o controle do trabalho da sua equipe, analisa commits relevantes, destaca problemas, sugere melhorias e protege seu código-base de alterações indesejadas.
5. Onboarding de desenvolvedores mais rápido: A Codacy pode ajudar a integrar novos desenvolvedores mais rapidamente ao projeto.
6. Gestão de dívida técnica e cobertura de código: Usar uma ferramenta de análise de código estático como a Codacy mudará a forma como sua equipe lida com revisões de código e PR, rastreia dívida técnica e cobertura de código e gerencia a qualidade geral do seu código.

Proposta

Implementar a ferramenta de code review Codacy em nosso projeto. Isso envolverá as seguintes etapas:

1. Criar uma conta na Codacy.
2. Configurar nosso repositório no Codacy.
3. Configurar as regras de code review no Codacy de acordo com nossas diretrizes de codificação.
4. Integrar a Codacy com nosso sistema de integração contínua.

Importante: A configuração dessa ferramenta deve ser feita por um dos mantenedores do projeto para garantir que as configurações estejam alinhadas com as diretrizes do projeto.

Critérios de Aceitação

• [ ] Conta na Codacy criada.
• [ ] Repositório configurado no Codacy.
• [ ] Regras de code review configuradas.
• [ ] Codacy integrada com nosso sistema de integração contínua.

Tarefas

• [ ] Criar conta na Codacy.
• [ ] Configurar repositório no Codacy.
• [ ] Configurar regras de code review.
• [ ] Integrar Codacy com sistema de integração contínua.

Exemplo

Algumas imagens do dashboard do codacy:

Sugestão de implementação

No response

[Rafatcb]

Obrigado pela sugestão bem detalhada, Emerson!

O que me chamou atenção para esse issue agora é que eu abri um PR resolvendo uns problemas apontados pelo DeepScan, e alguns problemas não são detectáveis com ESLint em JavaScript (em TypeScript já seriam).

Resolvi testar o Codacy num fork do TabNews e vi que ele realmente apontou algo chato de perceber, como um link para um fragmento inválido no Markdown (regra MD051).

Existem pontos debatíveis, como a proposta de usar no máximo 80 caracteres na linha no Markdown (regra MD013). O racional por trás dessa proposta é que é difícil trabalhar com linhas longas em alguns editores (o que é verdade).

O ponto chato dessas ferramentas são os falso-positivos, então é interessante que ela tenha poucos para não atrapalhar mais do que ajuda. Por exemplo, a regra Unnecessary Block (JavaScript) tem 52 alertas em try {, return {, template string, atribuição via desestruturação e até mesmo na abertura do corpo de uma função com parâmetros longos. Não analisei caso a caso, mas todos que vi eram falso-positivos. As regras de NoSQL/SQL Injection também parecem cair nesse caso de vários falso-positivos.

O problema em desativar essas regras que tem muito falso-positivos é que, se a regra de fato pegasse apenas o que deveria, seria bem útil.

Será interessante testar novamente após o merge do #1629, que inclui mais regras ESLint que já apontam problemas que o Codacy detectou.

Não testei a cobertura de código para ver se é a mesma coisa que o Jest consegue disponibilizar.

Você (ou outra pessoa) já usou o Codacy para opinar sobre o impacto no uso dele no dia-a-dia? Conhece outras ferramentas concorrentes?

[Rafatcb]

Fiz mais um teste agora, já que a branch com atualizações do ESLint foi mesclada, analisando apenas a parte de Quality do Codacy. Desativei as seguintes regras porque continham muitos falso-positivos ou eram regras que não pareciam relevantes para o nosso projeto:

• MD013 - Line length.
• MD033 - Inline HTML
• Security: Detect object injection
• Unnecessary Block
• rules_lgpl_javascript_database_rule-node-nosqli-injection
• javascript_pathtraversal_rule-non-literal-fs-filename (aqui poderíamos desabilitar em arquivos específicos)
• rules_lgpl_javascript_database_rule-node-sqli-injection
• node-postgres-sqli
• rules_lgpl_javascript_generic_rule-node-username
• Innaccurate Numeric Literal
• rules_lgpl_javascript_crypto_rule-node-insecure-random-generator
• insecure-document-method

Veja, tem regras que seriam bem úteis, mas os avisos "errados" fazem com que nós desativemos, e então a análise de código deixa de fazer sentido.

Antes de desativar as regras	Depois de desativas as regras

Diminuiu de 204 para 70 issues, mas só de entrar na página já percebi que tinha uma regra desativada que ainda estava presente na lista de issues. Veja também que 60 issues são de estilo de código, ou seja, não necessariamente é algo errado.

Enfim, o que mais incomoda é ter tanto trabalho para no fim ter apenas falso-positivos, então minha pergunta do comentário anterior sobre relatos continua de pé.

[emerson-oliveira]

Na empresa usamos como uma ferramenta de validação de erros de segurança e boas práticas. Talvez faça sentido explorar o SonarCube com segunda opção. E avaliar a ferramenta que faz mais sentido dentro das validações que consideram mais relevantes para o momento.