Decoding code review - Tech & Beers

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. DECODING CODE REVIEW Tech & Beers - 2022
2. Software Engineer/Developer (since 2008) B.Sc. in Computer Engineering M.Sc. in Computer Science ELAINE NAOMI WATANABE twitter.com/elaine_nw speakerdeck.com/elainenaomi
3. Software Engineer/Developer (since 2008) B.Sc. in Computer Engineering M.Sc. in Computer Science ELAINE NAOMI WATANABE twitter.com/elaine_nw speakerdeck.com/elainenaomi slides disponíveis
4. Software Engineer/Developer (since 2008) B.Sc. in Computer Engineering M.Sc. in Computer Science ELAINE NAOMI WATANABE twitter.com/elaine_nw speakerdeck.com/elainenaomi último evento presencial em março/2020 saudades </3
5. por onde esta palestra andou? Agile Trends The DevConf - São Paulo GURU SP Ada Lovelace Day - Curitiba Rubyconf Brasil - Trilha Codamos SourceLevel - Webinar 2019 - 2020
6. EXPECTATIVAS
7. EXPECTATIVAS discutir os desafios e práticas da revisão de código
8. Quem aqui revisa código no dia a dia? É um processo importante para vocês?
9. ...
10. DEFINIÇÃO PRÁTICAS DO DIA A DIA DESAFIOS APRENDIZADOS
11. PRÁTICAS DO DIA A DIA DESAFIOS APRENDIZADOS DEFINIÇÃO
12. CODE REVIEW processo de verificação de um sistema por meio da análise do código fonte, realizada por humanos https://en.wikipedia.org/wiki/Code_review
13. CODE REVIEW processo de verificação de um sistema por meio da análise do código fonte, realizada por humanos https://en.wikipedia.org/wiki/Code_review
16. qual é o objetivo?
19. 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
21. 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
22. 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 capacidade de adaptação ao longo do tempo
23. como é a evolução de um software?
24. é sempre fácil alterar uma base de código?
25. ...
27. Dívida Técnica Custo da mudança Tempo How to Monetize Application Technical Debt, Gartner, 2011
28. This is fine.
29. e tudo bem mesmo faz parte
30. mas e se a gente nunca olhar para essa dívida técnica?
31. Valor de negócio Custo da mudança Tempo How to Monetize Application Technical Debt, Gartner, 2011
32. Dívida Técnica Valor de negócio Custo da mudança Tempo How to Monetize Application Technical Debt, Gartner, 2011
33. o processo de code review é uma forma de reduzir a dívida técnica
34. costuma ter um custo menor de mudança em relação à correção de defeitos em produção
35. http://agilemodeling.com/essays/modelReviews.htm Desenv. Custo da mudança Tempo Requisitos Análise e Design Revisão Testes Produção
36. http://agilemodeling.com/essays/modelReviews.htm Desenv. Custo da mudança Tempo Requisitos Análise e Design Revisão Testes Produção custo maior de mudança
37. e pode impactar positivamente na qualidade de software
38. QUALIDADE DE SOFTWARE Confiabilidade Corretude Eficiência Manutenabilidade Valor de negócio https://en.wikipedia.org/wiki/Software_quality
39. é sobre impacto a longo prazo!
40. é sobre impacto a longo prazo!
41. ...
42. DEFINIÇÃO PRÁTICAS DO DIA A DIA DESAFIOS APRENDIZADOS
43. DEFINIÇÃO PRÁTICAS DO DIA A DIA DESAFIOS APRENDIZADOS
44. como fazer uma revisão de código?
45. Pair Programming Pull Request
46. Pair Programming Pull Request
47. Pair Programming Pull Request Merge Request or Change Request
49. documento sobre uma alteração
50. título
51. descrição
52. pessoas revisoras
53. revisão por meio de comentários
55. comparação do código atual com a alteração proposta
57. ...
58. por que usar pull requests?
59. Pair Programming Pull Request
60. Pair Programming Pull Request código + contexto de negócio
61. Pair Programming Pull Request histórico acessível das discussões
63. RubyConf 2018 - A Branch in Time https://www.youtube.com/watch?v=8OOTVxKDwe0
64. RubyConf 2018 - A Branch in Time https://www.youtube.com/watch?v=8OOTVxKDwe0 capture the why, not the what
65. ...
66. 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.
67. Trabalho Remoto
69. ...
70. transferência de conhecimento mentoria
72. visibilidade das alterações para outros times team awareness
74. ...
75. boas práticas
76. ...
77. como pessoa autora
78. Título explicativo Motivação (contexto de negócio) Lista de dúvidas e discussões prévias Gifs, screenshots das alterações
79. Mensagens de commits coerentes Código completo, testado Alterações pequenas Single responsibility principle
80. Revisar seu próprio PR Marcar pessoas como revisoras Aplicar as alterações necessárias Responder a todos os comentários
81. Dica: Templates de Pull Requests
82. https://help.github.com/pt/github/creating-cloning-and-archiving-repositories/creating-a-template-repository
83. ...
84. como pessoa revisora
85. Identificar defeitos (bugs) Sugerir soluções alternativas, refatorações Reforçar padrões de código e design Validar funcionalidade (código + negócio)
86. Identificar problemas de segurança Analisar impactos na performance Sugerir documentações Validar a qualidade do código-fonte
87. Conhecer novas funcionalidades Aprender novas tecnologias Compartilhar conhecimento e dúvidas
88. ...
89. DEFINIÇÃO PRÁTICAS DO DIA A DIA DESAFIOS APRENDIZADOS
90. DEFINIÇÃO PRÁTICAS DO DIA A DIA DESAFIOS APRENDIZADOS
92. ...
93. Fonte: https://mtlynch.io/human-code-reviews-1/
94. ...
95. visibilidade
96. Ferramentas para notificações de PRs Métricas de acompanhamento do projeto Monitoração de bugs
97. ...
98. impacto no tempo de entrega
100. 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
101. 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
102. mágica?
103. alinhamento
105. Sua base de código parece ter sido escrita por ÚNICA PESSOA? SIM NÃO Fonte: Talking with Tech Leads - Patrick Kua
106. ...
107. collective code ownership https://martinfowler.com/bliki/CodeOwnership.html
108. Fonte: https://mtlynch.io/human-code-reviews-2/
109. quem faz review, faz parte da construção da solução também
110. como ir nessa direção?
111. ...
112. como pessoa
113. ...
114. lembre-se que o feedback deve ser sobre o código, e não sobre as pessoas
115. ninguém acorda e pensa: vou lá adicionar um bug e já volto
116. ...
117. apoie a participação de TODAS AS PESSOAS do seu time
118. não é porque alguém é experiente, que não vai errar
119. não é porque alguém é iniciante, que não vai ter contribuição
120. ...
121. use comentários explícitos e descritivos
123. é para eu jogar fora a minha alteração?
124. ah, era só para apagar o espaço extra
125. ...
126. comentários repetitivos sobre estilo de código
127. podem ser substituídos por uma ferramenta de análise de código
131. ...
132. melhorias de design podem ser entregues em outro pull request
133. ...
134. se chegar a uma conclusão estiver difícil
135. não se limite à ferramenta de review
136. videoconferência presencialmente https://blog.plataformatec.com.br/2018/11/trabalhando-com-times-distribuidos/
137. videoconferência presencialmente ? https://blog.plataformatec.com.br/2018/11/trabalhando-com-times-distribuidos/ o que vocês acham?
139. documente as decisões e discussões offline
140. ...
141. preste atenção na sua forma de se comunicar
142. muitas vezes não é óbvio que um comentário ou comportamento é prejudicial
143. peça feedbacks muitas vezes não é óbvio que um comentário ou comportamento é prejudicial
144. leia sobre comunicação não-violenta muitas vezes não é óbvio que um comentário ou comportamento é prejudicial
145. leia sobre vieses inconscientes muitas vezes não é óbvio que um comentário ou comportamento é prejudicial
146. ...
147. como organização
148. ...
149. tenha critérios bem definidos ex.: o número mínimo de aprovações
150. atenção aos silos de conhecimento http://blog.plataformatec.com.br/2018/07/como-evitar-silos-de-conhecimento-na-sua-c odebase-e-levar-seus-code-reviews-para-o-proximo-nivel/ bus factor
151. ...
152. fator social
154. 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 inclusos, o PR tem 17% mais chance de ser aceito fator técnico
155. 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.
156. ...
157. formalize as recomendações, crie guidelines também sobre aspectos comportamentais
158. comunicação verbal, não verbal e escrita
160. comportamentos tóxicos
161. 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)
162. "como assim você não sabe isso???"
163. "como deixaram você entrar aqui??"
164. "vou ter que te explicar de novo?"
165. 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
166. como evitar isso?
167. Faça reviews como seres humanos https://mtlynch.io/human-code-reviews-1/ https://mtlynch.io/human-code-reviews-2/
168. ask, don't tell
169. ok, é só perguntar
170. ok, é só perguntar
171. "Testes não são importantes pra vc?" pergunta sarcástica, com julgamento pessoal
172. "Testes não são importantes pra vc?" pergunta sarcástica, com julgamento pessoal
173. "Esse PR não pode ser mergeado" comentário opinativo, sem ação concreta, imperativo
174. "Esse PR não pode ser mergeado" comentário opinativo, sem ação concreta, imperativo
175. "Por que não criou uma nova classe?" pergunta com julgamento pessoal ainda "como você não pensou nisso?"
176. "Por que não criou uma nova classe?" pergunta com julgamento pessoal ainda "como você não pensou nisso?"
177. busque comentar de maneira construtiva
178. construtivo "O que você acha sobre extrair essa lógica para uma classe? Acredito que vai melhorar a legibilidade e reduzir a complexidade"
179. 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?"
180. ...
181. DEFINIÇÃO PRÁTICAS DO DIA A DIA DESAFIOS APRENDIZADOS
182. DEFINIÇÃO PRÁTICAS DO DIA A DIA DESAFIOS APRENDIZADOS
183. desenvolvimento de software tem muito a ver com cultura e comunicação
184. "A cultura não faz as pessoas, as pessoas fazem a cultura" Chimamanda Ngozi Adichie
185. olhe para o seu time
186. diversidade ajuda a estimular empatia
187. pode ajudar a reduzir comportamentos tóxicos
188. e impactar positivamente na inovação e lucro
189. 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
190. olhe também para o ambiente fatores não-técnicos
191. 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.
192. a qualidade do software reflete todos esses fatores
193. impacta também no código escrito
194. código escrito é uma forma de comunicação
195. Donald Knuth. "Literate Programming (1984)" in Literate Programming. CSLI, 1992, pg. 99. "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."
196. code review é sobre cultura, pessoas, qualidade de software
197. e aí, como é o code review no seu dia a dia?
198. ...
199. https://sourcelevel.io/code-review-ebook
200. ...
201. minhas referências
204. google.github.io/eng-practices/review/reviewer/standard.html
210. github.com/joho/awesome-code-review 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/
211. 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-YE1DBz 7hCvPMf8q6O1ogI/preview Talking with Tech Leads - Patrick Kua youtube.com/watch?v=dNE6aqkG7ss
212. 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
213. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
214. All the little things - Sandi Metz https://www.youtube.com/watch?v=8bZh5LMaSmE
215. ...
217. Lessons Learned from Elixir Learning Paths https://www.youtube.com/watch?v=I1jUWz1RP2U https://speakerdeck.com/elainenaomi/elixir-conf-eu-lessons-learned-from-elixir-learning-paths
218. ...
219. https://twitter.com/rla4/status/1097982806163185666
220. ...
221. railsgirls.com.br
225. CARNIVAL EDITION
227. speakerdeck.com/elainenaomi elainenaomi.dev Muito obrigada illustrations from undraw.co