TDC SP 2019 - 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. Elaine Naomi Watanabe twitter.com/elaine_nw speakerdeck.com/elainenaomi Desenvolvedora de Software (Plataformatec) Mestrado em Ciência da Computação (USP)
3. careers.plataformatec.com.br
4. expectativas: discutir os desafios e práticas da revisão de código
5. definição práticas do dia a dia desafios aprendizados
6. definição práticas do dia a dia desafios aprendizados
7. 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
8. 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
9. qual é o objetivo?
12. 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
14. 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
15. Dívida Técnica Valor de negócio Custo da mudança tempo How to Monetize Application Technical Debt, Gartner, 2011
17. http://agilemodeling.com/essays/modelReviews.htm Desenv. custo da mudança tempo Requisitos Análise e Design Revisão Testes Produção
18. http://agilemodeling.com/essays/modelReviews.htm Desenv. custo da mudança tempo Requisitos Análise e Design Revisão Testes Produção
19. QUALIDADE DE SOFTWARE Confiabilidade Corretude Eficiência Manutenabilidade Valor de negócio https://en.wikipedia.org/wiki/Software_quality
20. ...
21. aprendizados definição práticas do dia a dia desafios
22. como fazer um code review?
23. como pessoa revisora
24. Pair Programming Pull Request
25. Pair Programming Pull Request
26. Fonte: https://mtlynch.io/human-code-reviews-2/
27. ...
28. Pair Programming Pull Request código + contexto de negócio
29. Pair Programming Pull Request histórico acessível das discussões
30. 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.
32. revisão por meio de comentários
34. transferência de conhecimento mentoria
35. visibilidade das alterações para outros times team awareness
36. boas práticas
37. como pessoa autora
38. Título explicativo Motivação (contexto de negócio) Lista de dúvidas e discussões prévias Gifs, screenshots das alterações
39. Mensagens de commits coerentes Código completo, testado Alterações pequenas Single responsibility principle
40. Marcar pessoas como revisoras Aplicar as alterações necessárias Responder a todos os comentários
41. ...
42. como pessoa revisora
43. Identificar defeitos (bugs) Sugerir soluções alternativas, refatorações Reforçar padrões de código e design Validar funcionalidade (código + negócio)
44. Identificar problemas de segurança Analisar impactos na performance Sugerir documentações Validar a qualidade do código-fonte
45. Conhecer novas funcionalidades Aprender novas tecnologias Compartilhar conhecimento e dúvidas
46. ...
47. definição práticas do dia a dia desafios aprendizados
48. Fonte: https://mtlynch.io/human-code-reviews-1/
50. 70% das alterações do Google são integradas em menos de 24h após o pedido de review 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
51. Alterações pequenas, uma pessoa revisora e sem comentários além de autorização para integração 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
52. mágica?
53. alinhamento
54. Sua base de código parece ter sido escrita por ÚNICA PESSOA? SIM NÃO Fonte: Talking with Tech Leads - Patrick Kua
55. collective code ownership https://martinfowler.com/bliki/CodeOwnership.html
56. Fonte: https://mtlynch.io/human-code-reviews-2/
57. quem faz review, faz parte da construção da solução também
58. como ir nessa direção?
59. ...
60. como pessoa
61. ...
62. lembre-se que o feedback deve ser sobre o código, e não sobre as pessoas
63. ninguém acorda e pensa: vou lá adicionar um bug e já volto
64. ...
65. apoie a participação de TODAS AS PESSOAS do seu time
66. não é porque alguém é experiente, que não vai errar
67. não é porque alguém é iniciante, que não vai ter contribuição
68. ...
69. use comentários explícitos e descritivos
71. é para eu jogar fora a minha alteração?
72. ah, era só para apagar o espaço extra
73. ...
74. comentários repetitivos sobre estilo de código
75. podem ser substituídos por uma ferramenta de análise de código
78. CÓDIGO: ELAINE 50% por 6 meses
79. ...
80. melhorias de design podem ser entregues em outro pull request
81. ...
82. se chegar a uma conclusão estiver difícil
83. não se limite à ferramenta de review
84. videoconferência presencialmente http://blog.plataformatec.com.br/2018/11/trabalhando-com-times-distribuidos/
85. documente as decisões e discussões offline
86. ...
87. preste atenção na sua forma de se comunicar
88. muitas vezes não é óbvio que um comentário ou comportamento é prejudicial
89. ...
90. como organização
91. ...
92. tenha critérios bem definidos ex.: o número mínimo de aprovações
93. ...
94. fator social
96. 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
97. 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.
98. ...
99. formalize as recomendações, crie guidelines sobre aspectos comportamentais
100. comunicação verbal, não verbal e escrita
102. comportamentos tóxicos
103. 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)
104. "como assim você não sabe isso???"
105. "como deixaram você entrar aqui??"
106. "vou ter que te explicar de novo?"
107. A análise de sentimento em comentários tem mostrado evidências de que comentários com tom negativo tendem a ser menos úteis 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
108. como evitar isso?
109. Faça reviews como seres humanos https://mtlynch.io/human-code-reviews-1/ https://mtlynch.io/human-code-reviews-2/
110. ask, don't tell
111. ok, é só perguntar
112. ok, é só perguntar
113. "Testes não são importantes pra vc?" pergunta sarcástica, com julgamento pessoal
114. "Testes não são importantes pra vc?" pergunta sarcástica, com julgamento pessoal
115. "Esse PR não pode ser mergeado" comentário opinativo, sem ação concreta, imperativo
116. "Esse PR não pode ser mergeado" comentário opinativo, sem ação concreta, imperativo
117. "Por que não criou uma nova classe?" pergunta com julgamento pessoal ainda "como você não pensou nisso?"
118. "Por que não criou uma nova classe?" pergunta com julgamento pessoal ainda "como você não pensou nisso?"
119. busque comentar de maneira construtiva
120. construtivo "O que você acha sobre extrair essa lógica para uma classe? Acredito que vai melhorar a legibilidade e reduzir a complexidade"
121. 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?"
122. ...
123. definição práticas do dia a dia desafios aprendizados
124. desenvolvimento de software tem muito a ver com cultura
125. "A cultura não faz as pessoas, as pessoas fazem a cultura" Chimamanda Ngozi Adichie
128. olhe para o seu time
129. diversidade ajuda a estimular empatia
130. pode ajudar a reduzir comportamentos tóxicos
131. e impactar positivamente na inovação e lucro
132. 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
133. olhe também para o ambiente fatores não-técnicos
134. 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.
135. a qualidade do software reflete todos esses fatores
136. impacta também no código escrito
137. código escrito é uma forma de comunicação
138. "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.
139. code review é sobre cultura, pessoas, qualidade de software
140. e aí, como é o code review no seu dia a dia?
141. minhas referências
150. 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/
151. 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 Arquitetura, pragmatismo e simplicidade - Roberta Arcoverde docs.google.com/presentation/d/1DMpfVcXtALeCPwQwTM0Nz-YE1D Bz7hCvPMf8q6O1ogI/preview Talking with Tech Leads - Patrick Kua youtube.com/watch?v=dNE6aqkG7ss
152. 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 Integração Discreta: como melhorar a Integração Contínua e ainda ganhar em colaboração - George Guimarães infoq.com/br/presentations/integracao-discreta-como-melhorar
153. https://twitter.com/rla4/status/1097982806163185666
155. muito obrigada speakerdeck.com/elainenaomi CÓDIGO: ELAINE 50% por 6 meses