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

F6d5a605df582ab9ea419ebef9f400b7?s=47 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.

F6d5a605df582ab9ea419ebef9f400b7?s=128

Caio Carrara

September 12, 2019
Tweet

Transcript

  1. 2.

    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. 3.

    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. 4.
  4. 5.
  5. 6.
  6. 7.
  7. 8.

    • 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...
  8. 12.

    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
  9. 13.

    Revisões leves, atual • Revisões baseadas em mudanças • Menor

    contexto para revisar • Revisões individuais • Maior auxílio ferramental
  10. 17.

    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)
  11. 21.

    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)
  12. 22.

    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)
  13. 23.

    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
  14. 24.

    Revisão de código Uma abordagem centrada em papéis • A

    pessoa que revisora • A pessoa autora
  15. 25.

    Pessoa revisora de código Dicas e soluções • Premissas •

    Aspectos técnicos • Aspectos humanos
  16. 26.

    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
  17. 27.

    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
  18. 28.
  19. 29.

    Revisão - o que observar? • Aspectos positivos • Funcionalidade

    ◦ Faz sentido a implementação? ◦ A funcionalidade é boa para usuários?
  20. 30.

    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
  21. 31.

    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
  22. 32.

    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?
  23. 33.

    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
  24. 34.

    Revisão - o que observar? • Aspectos positivos • Funcionalidade

    • Design • Complexidade • Testes • Nomes • Documentação ◦ A alteração afeta ▪ Build? ▪ Testes? ▪ API?
  25. 35.

    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
  26. 36.

    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
  27. 37.

    Revisão - importante! • Qual a natureza da sua requisição?

    ◦ Obrigatórias (críticas) ◦ Opcionais
  28. 38.

    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
  29. 40.

    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?”
  30. 41.

    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?”
  31. 42.

    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
  32. 43.

    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
  33. 44.

    Pessoa autora de código Dicas e soluções • O que

    fazer antes de submeter uma alteração de código
  34. 45.

    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
  35. 46.

    Submissão de código • As submissões devem ser pequenas •

    Refactorings devem ser submetidos separadamente
  36. 47.

    Submissão de código • As submissões devem ser pequenas •

    Refactorings devem ser submetidos separadamente • Disponibilize informações relevantes
  37. 48.

    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
  38. 49.

    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
  39. 50.

    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
  40. 52.

    Anti-Patterns “Respostas / ações comumente utilizadas em situações recorrentes mas

    que são ineficientes, ineficazes e podem até levar ao erro”
  41. 58.

    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