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.

Transcript

1. Revisão de Código Desafios, soluções e experiências Caio Carrara eu@caiocarrara.com.br
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
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
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...
9. Revisão de código Desafios, soluções e experiências https://caiocarrara.com.br/blog/
10. Revisão de código Desafios, soluções e experiências https://google.github.io/eng-practices/
11. Revisão de código - o que é?
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
13. Revisões leves, atual • Revisões baseadas em mudanças • Menor contexto para revisar • Revisões individuais • Maior auxílio ferramental
14. Revisões leves, atual • Linux Kernel (patch emails)
15. Revisões leves, atual • OpenStack (Gerrit)
16. Revisões leves, atual • Django (GitHub Pull Requests)
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)
18. Revisão de código é bom mesmo?
19. Estudos sobre Revisão de Código 2013
20. Estudos sobre Revisão de Código 2015
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)
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)
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
24. Revisão de código Uma abordagem centrada em papéis • A pessoa que revisora • A pessoa autora
25. Pessoa revisora de código Dicas e soluções • Premissas • Aspectos técnicos • Aspectos humanos
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
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
28. Revisão - o que observar? • Aspectos positivos ◦ Boas ideias ◦ Soluções inovadoras
29. Revisão - o que observar? • Aspectos positivos • Funcionalidade ◦ Faz sentido a implementação? ◦ A funcionalidade é boa para usuários?
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
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
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?
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
34. Revisão - o que observar? • Aspectos positivos • Funcionalidade • Design • Complexidade • Testes • Nomes • Documentação ◦ A alteração afeta ▪ Build? ▪ Testes? ▪ API?
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
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
37. Revisão - importante! • Qual a natureza da sua requisição? ◦ Obrigatórias (críticas) ◦ Opcionais
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
39. Revisão - aspectos humanos • Nunca falte com o respeito
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?”
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?”
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
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
44. Pessoa autora de código Dicas e soluções • O que fazer antes de submeter uma alteração de código
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
46. Submissão de código • As submissões devem ser pequenas • Refactorings devem ser submetidos separadamente
47. Submissão de código • As submissões devem ser pequenas • Refactorings devem ser submetidos separadamente • Disponibilize informações relevantes
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
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
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
51. Python Anti-Patterns
52. Anti-Patterns “Respostas / ações comumente utilizadas em situações recorrentes mas que são ineficientes, ineficazes e podem até levar ao erro”
53. Python Anti-Patterns • Corretude • Manutenabilidade • Legibilidade • Segurança • Performance • Django
54. Python Anti-Patterns - Corretude • Acessar membros internos (protegidos) de uma classe
55. Python Anti-Patterns - Manutenabilidade • Wildcard imports
56. Python Anti-Patterns - Manutenabilidade • Abrir arquivos sem context manager
57. Python Anti-Patterns - Legibilidade • map() ou filter() ao invés de List Comprehensions
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
59. Obrigado Revisão de Código - desafios, soluções e experiências Caio Carrara eu@caiocarrara.com.br