Guru SP: Decodificando o code review

Quando iniciamos a jornada como pessoa desenvolvedora, temos infinitas possibilidades para explorar, desde as boas práticas de design de código a questões como criação de interfaces, integrações com serviços, etc. E, por mais que nos preparemos para tudo, acabamos deixando de lado questões mais humanas em prol de questões mais técnicas. No entanto, o fator humano gera grande impacto na qualidade do software gerado, seja a curto ou a longo prazo. E o processo de code review traz, indiretamente, esse assunto em pauta.

Nessa palestra, vamos discutir o code review, analisando como a forma como a comunicação pode afetar não só a qualidade do software mas também a interação entre as pessoas.

Transcript

1. decodificando o CODE REVIEW
2. Desenvolvedora de Software (Plataformatec) Mestre em Ciência da Computação (USP) Elaine Naomi Watanabe github.com/elainenaomi twitter.com/elaine_nw
3. expectativas: discutir os desafios e práticas da revisão de código
4. https://en.wikipedia.org/wiki/Code_review CODE REVIEW processo de verificação de um sistema por meio da análise do código fonte, realizada por humanos
5. https://en.wikipedia.org/wiki/Code_review CODE REVIEW processo de verificação de um sistema por meio da análise do código fonte, realizada por humanos
6. qual é o objetivo?
9. 60% dos defeitos podem ser identificados na revisão do código Boehm, Barry, and Victor R. Basili. "Top 10 list [software development]." Computer 34.1 (2001): 135-137
10. http://agilemodeling.com/essays/modelReviews.htm Desenv. custo da mudança tempo Requisitos Análise e Design Revisão Testes Produção
11. http://agilemodeling.com/essays/modelReviews.htm Desenv. custo da mudança tempo Requisitos Análise e Design Revisão Testes Produção
12. QUALIDADE DE SOFTWARE Confiabilidade Corretude Eficiência Manutenabilidade Valor de negócio https://en.wikipedia.org/wiki/Software_quality
13. Dívida Técnica Valor de negócio Custo da mudança tempo How to Monetize Application Technical Debt, Gartner, 2011
15. Revisão de código é uma boa ferramenta para identificar defeitos relacionados à evolutibilidade do código que não são identificáveis na fase de testes Mäntylä, Mika V., and Casper Lassenius. "What types of defects are really discovered in code reviews?." IEEE Transactions on Software Engineering 35.3 (2009): 430-448
16. como fazer um code review?
17. como pessoa revisora
18. Pair Programming Pull Request
19. Pair Programming Pull Request
20. Pair Programming Pull Request código + contexto de negócio
21. Pair Programming Pull Request histórico acessível das discussões
22. interação assíncrona distribuída Mesmo local Mesmo tempo Tempo diferente Locais diferentes interação síncrona distribuída interação assíncrona interação face-a-face Johansen, Robert. "Groupware: Future directions and wild cards." Journal of Organizational Computing and Electronic Commerce 1.2 (1991): 219-227.
24. revisão por meio de comentários
26. visibilidade das alterações para outros times team awareness
27. transferência de conhecimento mentoria
28. boas práticas
29. ...
30. como pessoa autora
31. Título explicativo Motivação (contexto de negócio) Lista de dúvidas e discussões prévias Gifs, screenshots das alterações
32. Mensagens de commits coerentes Código completo, testado Alterações pequenas Single responsibility principle
33. marque pessoas como revisoras
34. aplique as alterações necessárias
35. e responda a todos os comentários
36. ...
37. como pessoa revisora
38. Identificar defeitos (bugs) Sugerir soluções alternativas, refatorações Reforçar padrões de código e design Validar funcionalidade (código + negócio)
39. Identificar problemas de segurança Analisar impactos na performance Sugerir documentações Validar a qualidade do código-fonte
40. não esqueça é importante que os comentários sejam explícitos e descritivos
42. é para eu jogar fora a minha alteração?
43. ah, era só para apagar o espaço extra
44. o feedback deve ser sobre o código, e não sobre as pessoas
45. quem faz review, ajuda na construção da solução também collective code ownership
46. além disso
47. comentários repetitivos sobre estilo de código
48. podem ser substituídos por uma ferramenta de análise de código
49. melhorias de design podem ser entregues em outro pull request
50. se chegar a uma conclusão estiver difícil
51. não se limite à ferramenta de review
52. videoconferência presencialmente http://blog.plataformatec.com.br/2018/11/trabalhando-com-times-distribuidos/
53. documente as decisões e discussões offline
54. ...
55. como organização
56. tenha critérios bem definidos ex.: o número mínimo de aprovações
57. formalize as recomendações, crie guidelines sobre aspectos comportamentais
58. comunicação verbal, não verbal e escrita
59. ...
60. fator social
62. Tsay, Jason, Laura Dabbish, and James Herbsleb. "Influence of social and technical factors for evaluating contribution in GitHub." Proceedings of the 36th international conference on Software engineering. ACM, 2014. Quando os testes estão incluso, o PR tem 17% mais chance de ser aceito fator técnico
63. Se a pessoa autora segue a pessoa responsável pelo projeto, tem 187% mais chance do PR ser aceito fator social Tsay, Jason, Laura Dabbish, and James Herbsleb. "Influence of social and technical factors for evaluating contribution in GitHub." Proceedings of the 36th international conference on Software engineering. ACM, 2014.
64. PRs com grandes quantidades de comentários, têm chance menor de ser aceito no contexto open source fator social Tsay, Jason, Laura Dabbish, and James Herbsleb. "Influence of social and technical factors for evaluating contribution in GitHub." Proceedings of the 36th international conference on Software engineering. ACM, 2014.
66. comportamentos tóxicos
68. podia ser pior? com certeza!
69. podia ser pior? com certeza!
70. mas, ainda sim, é super tóxico
71. COMPORTAMENTOS TÓXICOS https://medium.com/@jgefroh/toxic-developers-considered-harmful-f7ea1494d4c0 Impedem inovações e ideias Promovem a cultura da não-comunicação Colocam o projeto e negócio em risco por centralizar informação Comunicação agressiva (verbal, não-verbal e escrita)
72. "como assim você não sabe isso???"
73. "como deixaram você entrar aqui??"
74. "vou ter que te explicar de novo?"
75. "Sentiment analysis on comments has provided evidence that comments with negative tone are less likely to be useful" Sadowski, Caitlin, et al. "Modern code review: a case study at Google." Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice. ACM, 2018
76. como evitar isso?
77. Faça reviews como seres humanos https://mtlynch.io/human-code-reviews-1/ https://mtlynch.io/human-code-reviews-2/
78. ask, don't tell
79. ok, é só perguntar
80. ok, é só perguntar
81. "Testes não são importantes pra vc?" pergunta sarcástica, com julgamento pessoal
82. "Testes não são importantes pra vc?" pergunta sarcástica, com julgamento pessoal
83. "Esse PR não pode ser mergeado" comentário opinativo, sem ação concreta, imperativo
84. "Esse PR não pode ser mergeado" comentário opinativo, sem ação concreta, imperativo
85. "Por que não criou uma nova classe?" pergunta com julgamento pessoal ainda "como você não pensou nisso?"
86. "Por que não criou uma nova classe?" pergunta com julgamento pessoal ainda "como você não pensou nisso?"
87. busque comentar de maneira construtiva
88. construtivo "O que você acha sobre extrair essa lógica para uma classe? Acredito que vai melhorar a legibilidade e reduzir a complexidade"
89. sem suposição, tom de sugestão "Não sei se você já analisou isso, mas será que não vale a pena criar uma nova classe para esse caso?"
90. software é também sobre cultura
91. "A cultura não faz as pessoas, as pessoas fazem a cultura" Chimamanda Ngozi Adichie
92. olhe para a diversidade do seu time
93. diversidade ajuda a estimular empatia
94. pode ajudar a reduzir comportamentos tóxicos
95. e impacta positivamente na inovação e lucro
96. https://assets.mckinsey.com/~/media/857F440109AA4D13A54D9C496D86ED58.ashx Diversidade de gênero: 21% mais chances de resultados acima da média do mercado Diversidade cultural e étnica: 33% mais chances de resultados acima da média do mercado
97. olhe também para o ambiente fatores não-técnicos
98. pressão, sobrecarga de atividades, experiência e contexto de negócio Baysal, Olga, et al. "The influence of non-technical factors on code review." 2013 20th Working Conference on Reverse Engineering (WCRE). IEEE, 2013.
99. a qualidade do software reflete todos esses fatores
100. impacta também no código escrito
101. código escrito é uma forma de comunicação
102. "Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." Donald Knuth. "Literate Programming (1984)" in Literate Programming. CSLI, 1992, pg. 99.
103. e aí, como está a qualidade do seu software?
104. minhas referências
113. guidelines.plataformatec.com.br github.blog/2015-01-21-how-to-write-the-perfect-pull-request medium.com/palantir/19e02780015f medium.com/@jgefroh/f7ea1494d4c0 forbes.com/sites/quora/2014/11/07/10-characteristics-of-a-bad-softwar e-engineer blog.plataformatec.com.br/2018/07/como-evitar-silos-de-conhecimento- na-sua-codebase-e-levar-seus-code-reviews-para-o-proximo-nivel/
114. Building an Iconic Company - Reed Hasting youtube.com/watch?v=BsXXIfqbnRk A Arquitetura (Peculiar) do Stack Overflow - Roberta Arcoverde infoq.com/br/presentations/a-arquitetura-peculiar-do-stack-overflow Implementing a Strong Code-Review Culture - Derek Prior youtube.com/watch?v=PJjmw9TRB7s Maintaining a big open source project: lessons learned - Leonardo Tegon youtube.com/watch?v=rnOcDH_sgxg
116. muito obrigada speakerdeck.com/elainenaomi