Latest / Entre Chaves / Snippet #32 SonarQube: o filtro antes do code review manual

Transcript

Snippet #32 SonarQube: o filtro antes do code review manual · Entre Chaves

• 0:00
  Meu nome é Gustavo Lyra. Sou desenvolvedor líder na DTI
• 0:02
  para um projeto Internacional e vim falar um pouco sobre como a
• 0:05
  revisão de código muda quando o código é feito com OIA.
• 0:07
  Não é que AIA escreva código ruim, a questão é que ela
• 0:10
  escreve código que parece certo e isso muda a forma como o code
• 0:13
  review precisa ser feito. Isso acontece porque
• 0:15
  sintaticamente o código, vem bonito a variável bem nomeada.
• 0:19
  O comentário pertinente, mas se a regra de negócio não foi
• 0:21
  explicitada, o modelo não sabe por que ela é daquele jeito.
• 0:24
  Ele só vinha um padrão repetido em milhões de repositórios e
• 0:27
  reproduziu a média. Na prática, isso vira 3
• 0:30
  problemas que aparecem com frequência e aí que ferramentas
• 0:32
  como o solarcloud entram, tirando do seu prato tudo que é
• 0:35
  mecânico para você focar no que só quem entende o negócio
• 0:38
  consegue avaliar. O primeiro problema é o código
• 0:40
  plausível, mas errado no contexto.
• 0:42
  A função funciona no caminho feliz e ignora aquele é de case
• 0:45
  que só existe no seu domínio. O teste passa porque AIA
• 0:47
  escreveu o teste também. E testou que ela achou que
• 0:50
  devia, não, que o negócio precisava.
• 0:51
  É aqui que a cobertura de testes e a complexidade cognitiva do
• 0:54
  sonar cloud entram. Ele mostra exatamente quais
• 0:56
  condições e brent não foram exercitados e aquele é de case
• 0:59
  que passou batido no caminho feliz.
• 1:01
  Fica visível já no code review, antes do PR ser completado, não
• 1:04
  depois em produção. O segundo é a duplicação
• 1:06
  silenciosa, o modelo não tem visão do projeto inteiro, então
• 1:09
  recriou um helper que já existe, só que com outro nome.
• 1:12
  Agora são 2 lugares para manter e o single Soccer of churse já
• 1:15
  quebrou sem ninguém decidir isso.
• 1:17
  O Senado detecta duplicação não só da.
• 1:19
  Do arquivo, mas no projeto inteiro e aponta os blocos
• 1:21
  repetidos e onde o consolidar. Mas antes que essa duplicação se
• 1:24
  multiplique em outros PRSO. Terceiro é a decisão de
• 1:27
  arquitetura tomada por acidente. Aí a escolhe uma libe, um
• 1:30
  padrão. Uma forma de lidar com o estado
• 1:32
  e ninguém decidiu aquilo, simplesmente entrou.
• 1:34
  A regra de negócio dentro de um controle é chamada de API,
• 1:37
  dentro de componente é limite de camada furado sem ninguém
• 1:39
  perceber. Os cold mels e os security
• 1:41
  hotspots do sonar marcam esses desvios de padrão direto na
• 1:44
  análise, o que dá para decidir antes do muj se aquilo foi uma
• 1:47
  escolha consciente ou uma decisão que entrou de carona.
• 1:50
  O volume de código sobe, a densidade de intenção por linha
• 1:53
  cai. Que você acaba revisando mais
• 1:54
  código do que a gente pensou. Isso não é um problema em si,
• 1:57
  mas transforma em um jogo diferente.
• 1:59
  Código humano mal escrito é difícil de ler, código de a bem
• 2:02
  escrito pode ser difícil de confiar e o que muda aqui é que
• 2:05
  entendeu o porquê da implementação, passava a ler
• 2:07
  mais do que entendeu. Como é isso que o Sana libera
• 2:09
  complexidade, duplicação, cobertura e hotspots já
• 2:13
  filtrados antes do PR ser completado.
• 2:15
  O que resta para o review é a intenção, e essa só quem entende
• 2:18
  o negócio consegue avaliar. E é isso, gente, obrigado pelo
• 2:20
  convite, até mais.