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

Revisão de Código - Desafios, soluções e experi...

Caio Carrara
September 12, 2019

Revisão de Código - Desafios, soluções e experiências

O processo de revisão de código está cada vez mais incorporado no ciclo de desenvolvimento de software de empresas. O que antes era uma atividade quase exclusiva em contribuições de projetos de código aberto agora já é padrão também em projetos internos. Entretanto nem todas as pessoas estão acostumadas com o processo de revisar o código alheio ou ter seu próprio código revisado. O despreparo de equipes quanto ao processo de revisão pode inclusive dimiuir a produtividade do time, afetar a qualidade do projeto e o relacionamento das pessoas.

Nessa apresentação serão expostas boas práticas para se adotar enquanto revisa o código de colegas bem como o que se atentar antes, durante e depois da própria submissão de código. Dada a natureza interpessoal da atividade serão abordados aspectos tanto de relacionamento e cuidados na comunicação mas também dicas do que se atentar ao revisar especificamente código escrito em Python.

Caio Carrara

September 12, 2019
Tweet

More Decks by Caio Carrara

Other Decks in Technology

Transcript

  1. Caio Carrara • Desenvolvedor de Software ◦ Loadsmart ◦ RedHat

    ◦ Olist ◦ ThoughtWorks • Contribuidor Open Source ◦ OpenStack ◦ PyLint ◦ QEMU ◦ Avocado • Code Review ◦ 2017 - 44% ◦ 2018 - 39% ◦ 2019 - 28% Tech Lead @ Loadsmart
  2. Agenda • Code Review ◦ Histórico e contexto • O

    papel da pessoa revisora ◦ Premissas ◦ Aspectos técnicos ◦ Aspectos humanos • O papel da pessoa autora • O que se atentar na revisão de código Python
  3. • Back End Engineer (Python) • Front End Engineer (React)

    • Full Stack Engineer • Site Reliability Engineer • Integration Engineer (EDI) loadsmart.com/careers • BI Analyst • Data Architect • Data Engineer • Data Science Engineer • Senior UI/UX Designer Dúvidas? Vem falar comigo...
  4. Inspeções Formais, 1976 • Reunião com todo time de desenvolvimento

    • Revisão linha por linha • Feita em tempos regulares • Algum resultado era esperado após a reunião https://ieeexplore.ieee.org/document/5388086
  5. Revisões leves, atual • Revisões baseadas em mudanças • Menor

    contexto para revisar • Revisões individuais • Maior auxílio ferramental
  6. Revisão de código Por quê? • Encontrar defeitos • Buscar

    soluções alternativas • Melhorar qualidade geral da base de código • Transferir conhecimento • Aumentar a consciência de time • Compartilhar senso de propriedade (code ownership)
  7. Estudos sobre Revisão de Código “Acreditamos que nossas descobertas provêm

    fortes evidências empíricas que apoiam a estrutura moderna de políticas de integração de código que levam a revisão de código em consideração” (tradução livre)
  8. Estudos sobre Revisão de Código “Nossos modelos [de análise dos

    dados] sugerem que tais políticas [de revisão de código] levam a um software de melhor qualidade e menos propenso a erros” (tradução livre)
  9. Revisão de código Desafios • É uma realidade e irá

    perdurar • Revisar é tão (ou mais) complexo que escrever código • Não somos treinados para revisar • Ineficiência e frustração • Comprometimento da relação interpessoal
  10. Revisão de código Uma abordagem centrada em papéis • A

    pessoa que revisora • A pessoa autora
  11. Pessoa revisora de código Dicas e soluções • Premissas •

    Aspectos técnicos • Aspectos humanos
  12. Revisão - premissas • Não existe código perfeito • Buscar

    e exigir perfeição é contraproducente • Estilo de código é trabalho do linter • Deve-se almejar sempre a melhoria da base de código
  13. Revisão - premissas • Não existe código perfeito • Buscar

    e exigir perfeição é contraproducente • Estilo de código é trabalho do linter • Deve-se almejar sempre a melhoria da base de código • Manutenabilidade • Legibilidade • Compreensividade
  14. Revisão - o que observar? • Aspectos positivos • Funcionalidade

    ◦ Faz sentido a implementação? ◦ A funcionalidade é boa para usuários?
  15. Revisão - o que observar? • Aspectos positivos • Funcionalidade

    • Design ◦ As interações entre as partes ◦ Separação de responsabilidades ◦ Alteração faz sentido onde foi implementada? ◦ Design deve ser tratado o quanto antes
  16. Revisão - o que observar? • Aspectos positivos • Funcionalidade

    • Design • Complexidade ◦ A alteração é facilmente compreendida ◦ O código está propenso a erros? ◦ Over-engineering? ◦ Complexidade ciclomática pode ser pedida pelo Flake8
  17. Revisão - o que observar? • Aspectos positivos • Funcionalidade

    • Design • Complexidade • Testes ◦ Código de teste também deve ser revisado ◦ O teste está claro? ◦ Se o teste falhar, é fácil compreender o que está errado?
  18. Revisão - o que observar? • Aspectos positivos • Funcionalidade

    • Design • Complexidade • Testes • Nomes ◦ Elementos estão bem nomeados? ◦ É fácil compreender a responsabilidade dos elementos pelo nome? ◦ Comentários devem se ater ao “porquê” e não ao “como” ◦ Se o código não se explica quanto ao “como” então deve ser reescrito
  19. Revisão - o que observar? • Aspectos positivos • Funcionalidade

    • Design • Complexidade • Testes • Nomes • Documentação ◦ A alteração afeta ▪ Build? ▪ Testes? ▪ API?
  20. Revisão - o que observar? • Aspectos positivos • Funcionalidade

    • Design • Complexidade • Testes • Nomes • Documentação • Linha por linha ◦ Código gerado até pode ser revisto por scan
  21. Revisão - o que observar? • Aspectos positivos • Funcionalidade

    • Design • Complexidade • Testes • Nomes • Documentação • Linha por linha • Contexto ◦ Olhar linhas além da alteração ◦ Pode haver duplicidades ◦ Pode haver quebra de responsabilidade
  22. Revisão - importante! • Qual a natureza da sua requisição?

    ◦ Obrigatórias (críticas) ◦ Opcionais
  23. Revisão - importante! • Qual a natureza da sua requisição?

    • Muitos comentários para fazer? ◦ Foque nos mais críticos / relevantes ◦ Não existe código perfeito ◦ Leve em consideração a pessoa autora da alteração
  24. Revisão - aspectos humanos • Nunca falte com o respeito

    • Restrinja os comentários sobre o código e não sobre a pessoa Ruim: “Por que você está resolvendo isso assim?” Melhor: “A implementação dessa forma está deixando o código mais complexo. O que acha dessa outra forma?”
  25. Revisão - aspectos humanos • Nunca falte com o respeito

    • Restrinja os comentários sobre o código e não sobre a pessoa • Explique suas posições Ruim: “Esse código está ruim” Melhor: “Essa alteração poderia ser feita dessa outra forma [explique como] pelos motivos 1, 2 e 3. O que você acha?”
  26. Revisão - aspectos humanos • Nunca falte com o respeito

    • Restrinja os comentários sobre o código e não sobre a pessoa • Explique suas posições • Encoraje a melhora do código ao invés de exigir explicações
  27. Revisão - aspectos humanos • Nunca falte com o respeito

    • Restrinja os comentários sobre o código e não sobre a pessoa • Explique suas posições • Encoraje a melhora do código ao invés de exigir explicações • Use a revisão como ferramenta de mentoria ◦ Busque comentários que agreguem ao conhecimento da pessoa autora ◦ Compartilhar conhecimento faz parte do processo
  28. Pessoa autora de código Dicas e soluções • O que

    fazer antes de submeter uma alteração de código
  29. Submissão de código • As submissões devem ser pequenas ◦

    Quanto mais linhas para revisar, menor é a participação de pessoas revisando ◦ Submissões maiores possuem comentários superficiais e escassos ◦ Maior agilidade na aceitação
  30. Submissão de código • As submissões devem ser pequenas •

    Refactorings devem ser submetidos separadamente
  31. Submissão de código • As submissões devem ser pequenas •

    Refactorings devem ser submetidos separadamente • Disponibilize informações relevantes
  32. Submissão de código • As submissões devem ser pequenas •

    Refactorings devem ser submetidos separadamente • Disponibilize informações relevantes • A melhor versão possível desde a primeira submissão ◦ Menor ciclos de feedback
  33. Submissão de código • As submissões devem ser pequenas •

    Refactorings devem ser submetidos separadamente • Disponibilize informações relevantes • A melhor versão possível desde a primeira submissão • Receba abertamente os comentários
  34. Revisão de código Python Uma última dica • Tudo o

    que vimos até aqui é relevante ao revisar código Python • Há mais um aspecto específico
  35. Anti-Patterns “Respostas / ações comumente utilizadas em situações recorrentes mas

    que são ineficientes, ineficazes e podem até levar ao erro”
  36. Revisão de código Desafios, soluções e experiências • Revisar código

    é vantajoso • Há desafios técnicos e humanos • Não somos ensinados, mas estamos aprendendo • Soluções ainda estão sendo formalizadas e compartilhadas