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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

6. EXPECTATIVAS
   

   View Slide

7. EXPECTATIVAS
   discutir os desafios e práticas da
   revisão de código
   

   View Slide

8. Quem aqui revisa código no dia a dia?
   É um processo importante para vocês?
   

   View Slide

9. ...
   

   View Slide

10. DEFINIÇÃO
    PRÁTICAS DO
    DIA A DIA
    DESAFIOS
    APRENDIZADOS
    

    View Slide

11. PRÁTICAS DO
    DIA A DIA
    DESAFIOS
    APRENDIZADOS
    DEFINIÇÃO
    

    View Slide

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
    

    View Slide

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
    

    View Slide

14. View Slide

15. View Slide

16. qual é o objetivo?
    

    View Slide

17. View Slide

18. View Slide

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
    

    View Slide

20. View Slide

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
    

    View Slide

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
    

    View Slide

23. como é a evolução de um software?
    

    View Slide

24. é sempre fácil alterar
    uma base de código?
    

    View Slide

25. ...
    

    View Slide

26. View Slide

27. Dívida Técnica
    Custo da mudança
    Tempo
    How to Monetize Application Technical Debt, Gartner, 2011
    

    View Slide

28. This is fine.
    

    View Slide

29. e tudo bem mesmo
    faz parte
    

    View Slide

30. mas e se a gente nunca olhar
    para essa dívida técnica?
    

    View Slide

31. Valor de negócio
    Custo da mudança
    Tempo
    How to Monetize Application Technical Debt, Gartner, 2011
    

    View Slide

32. Dívida Técnica
    Valor de negócio
    Custo da mudança
    Tempo
    How to Monetize Application Technical Debt, Gartner, 2011
    

    View Slide

33. o processo de code review é uma
    forma de reduzir a dívida técnica
    

    View Slide

34. costuma ter um custo menor de
    mudança em relação à correção de
    defeitos em produção
    

    View Slide

35. http://agilemodeling.com/essays/modelReviews.htm
    Desenv.
    Custo da mudança
    Tempo
    Requisitos
    Análise e
    Design
    Revisão Testes Produção
    

    View Slide

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
    

    View Slide

37. e pode impactar positivamente na
    qualidade de software
    

    View Slide

38. QUALIDADE DE SOFTWARE
    Confiabilidade
    Corretude
    Eficiência
    Manutenabilidade
    Valor de negócio
    https://en.wikipedia.org/wiki/Software_quality
    

    View Slide

39. é sobre impacto a longo prazo!
    

    View Slide

40. é sobre impacto a longo prazo!
    

    View Slide

41. ...
    

    View Slide

42. DEFINIÇÃO
    PRÁTICAS DO
    DIA A DIA
    DESAFIOS
    APRENDIZADOS
    

    View Slide

43. DEFINIÇÃO
    PRÁTICAS DO
    DIA A DIA
    DESAFIOS
    APRENDIZADOS
    

    View Slide

44. como fazer uma
    revisão de código?
    

    View Slide

45. Pair Programming
    Pull Request
    

    View Slide

46. Pair Programming
    Pull Request
    

    View Slide

47. Pair Programming
    Pull Request
    Merge Request or Change Request
    

    View Slide

48. View Slide

49. documento sobre uma alteração
    

    View Slide

50. título
    

    View Slide

51. descrição
    

    View Slide

52. pessoas
    revisoras
    

    View Slide

53. revisão por meio de comentários
    

    View Slide

54. View Slide

55. comparação do código atual com a
    alteração proposta
    

    View Slide

56. View Slide

57. ...
    

    View Slide

58. por que usar pull requests?
    

    View Slide

59. Pair Programming
    Pull Request
    

    View Slide

60. Pair Programming
    Pull Request
    código + contexto de negócio
    

    View Slide

61. Pair Programming
    Pull Request
    histórico acessível das discussões
    

    View Slide

62. View Slide

63. RubyConf 2018 - A Branch in Time
    https://www.youtube.com/watch?v=8OOTVxKDwe0
    

    View Slide

64. RubyConf 2018 - A Branch in Time
    https://www.youtube.com/watch?v=8OOTVxKDwe0
    capture the why,
    not the what
    

    View Slide

65. ...
    

    View Slide

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.
    

    View Slide

67. Trabalho
    Remoto
    

    View Slide

68. View Slide

69. ...
    

    View Slide

70. transferência de conhecimento
    mentoria
    

    View Slide

71. View Slide

72. visibilidade das alterações
    para outros times
    team awareness
    

    View Slide

73. View Slide

74. ...
    

    View Slide

75. boas práticas
    

    View Slide

76. ...
    

    View Slide

77. como pessoa autora
    

    View Slide

78. Título explicativo
    Motivação (contexto de negócio)
    Lista de dúvidas e discussões prévias
    Gifs, screenshots das alterações
    

    View Slide

79. Mensagens de commits coerentes
    Código completo, testado
    Alterações pequenas
    Single responsibility principle
    

    View Slide

80. Revisar seu próprio PR
    Marcar pessoas como revisoras
    Aplicar as alterações necessárias
    Responder a todos os comentários
    

    View Slide

81. Dica: Templates de Pull Requests
    

    View Slide

82. https://help.github.com/pt/github/creating-cloning-and-archiving-repositories/creating-a-template-repository
    

    View Slide

83. ...
    

    View Slide

84. como pessoa revisora
    

    View Slide

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)
    

    View Slide

86. Identificar problemas de segurança
    Analisar impactos na performance
    Sugerir documentações
    Validar a qualidade do código-fonte
    

    View Slide

87. Conhecer novas funcionalidades
    Aprender novas tecnologias
    Compartilhar conhecimento e dúvidas
    

    View Slide

88. ...
    

    View Slide

89. DEFINIÇÃO
    PRÁTICAS DO
    DIA A DIA
    DESAFIOS
    APRENDIZADOS
    

    View Slide

90. DEFINIÇÃO
    PRÁTICAS DO
    DIA A DIA
    DESAFIOS
    APRENDIZADOS
    

    View Slide

91. View Slide

92. ...
    

    View Slide

93. Fonte: https://mtlynch.io/human-code-reviews-1/
    

    View Slide

94. ...
    

    View Slide

95. visibilidade
    

    View Slide

96. Ferramentas para notificações de PRs
    Métricas de acompanhamento do projeto
    Monitoração de bugs
    

    View Slide

97. ...
    

    View Slide

98. impacto no
    tempo de entrega
    

    View Slide

99. View Slide

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
     

     View Slide

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
     

     View Slide

102. mágica?
     

     View Slide

103. alinhamento
     

     View Slide

104. View Slide

105. Sua base de código parece ter sido
     escrita por ÚNICA PESSOA?
     SIM NÃO
     Fonte: Talking with Tech Leads - Patrick Kua
     

     View Slide

106. ...
     

     View Slide

107. collective code ownership
     https://martinfowler.com/bliki/CodeOwnership.html
     

     View Slide

108. Fonte: https://mtlynch.io/human-code-reviews-2/
     

     View Slide

109. quem faz review, faz parte da
     construção da solução também
     

     View Slide

110. como ir nessa direção?
     

     View Slide

111. ...
     

     View Slide

112. como pessoa
     

     View Slide

113. ...
     

     View Slide

114. lembre-se que o feedback
     deve ser sobre o código,
     e não sobre as pessoas
     

     View Slide

115. ninguém acorda e pensa:
     vou lá adicionar um bug e já volto
     

     View Slide

116. ...
     

     View Slide

117. apoie a participação de
     TODAS AS PESSOAS do seu time
     

     View Slide

118. não é porque alguém é experiente,
     que não vai errar
     

     View Slide

119. não é porque alguém é iniciante,
     que não vai ter contribuição
     

     View Slide

120. ...
     

     View Slide

121. use comentários
     explícitos e descritivos
     

     View Slide

122. View Slide

123. é para eu jogar fora a minha alteração?
     

     View Slide

124. ah, era só para apagar o espaço extra
     

     View Slide

125. ...
     

     View Slide

126. comentários repetitivos
     sobre estilo de código
     

     View Slide

127. podem ser substituídos por uma
     ferramenta de análise de código
     

     View Slide

128. View Slide

129. View Slide

130. View Slide

131. ...
     

     View Slide

132. melhorias de design podem ser
     entregues em outro pull request
     

     View Slide

133. ...
     

     View Slide

134. se chegar a uma conclusão
     estiver difícil
     

     View Slide

135. não se limite à ferramenta de review
     

     View Slide

136. videoconferência
     presencialmente
     https://blog.plataformatec.com.br/2018/11/trabalhando-com-times-distribuidos/
     

     View Slide

137. videoconferência
     presencialmente ?
     https://blog.plataformatec.com.br/2018/11/trabalhando-com-times-distribuidos/
     o que vocês acham?
     

     View Slide

138. View Slide

139. documente as decisões e
     discussões offline
     

     View Slide

140. ...
     

     View Slide

141. preste atenção na sua
     forma de se comunicar
     

     View Slide

142. muitas vezes não é óbvio que um
     comentário ou comportamento é
     prejudicial
     

     View Slide

143. peça feedbacks
     muitas vezes não é óbvio que um
     comentário ou comportamento é
     prejudicial
     

     View Slide

144. leia sobre
     comunicação não-violenta
     muitas vezes não é óbvio que um
     comentário ou comportamento é
     prejudicial
     

     View Slide

145. leia sobre
     vieses inconscientes
     muitas vezes não é óbvio que um
     comentário ou comportamento é
     prejudicial
     

     View Slide

146. ...
     

     View Slide

147. como organização
     

     View Slide

148. ...
     

     View Slide

149. tenha critérios bem definidos
     ex.: o número mínimo de aprovações
     

     View Slide

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
     

     View Slide

151. ...
     

     View Slide

152. fator social
     

     View Slide

153. View Slide

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
     

     View Slide

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.
     

     View Slide

156. ...
     

     View Slide

157. formalize as recomendações,
     crie guidelines também sobre
     aspectos comportamentais
     

     View Slide

158. comunicação
     verbal, não verbal e escrita
     

     View Slide

159. View Slide

160. comportamentos
     tóxicos
     

     View Slide

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)
     

     View Slide

162. "como assim você não sabe isso???"
     

     View Slide

163. "como deixaram você entrar aqui??"
     

     View Slide

164. "vou ter que te explicar de novo?"
     

     View Slide

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
     

     View Slide

166. como evitar isso?
     

     View Slide

167. Faça reviews como seres humanos
     https://mtlynch.io/human-code-reviews-1/
     https://mtlynch.io/human-code-reviews-2/
     

     View Slide

168. ask, don't tell
     

     View Slide

169. ok, é só perguntar
     

     View Slide

170. ok, é só perguntar
     

     View Slide

171. "Testes não são importantes pra vc?"
     pergunta sarcástica, com julgamento pessoal
     

     View Slide

172. "Testes não são importantes pra vc?"
     pergunta sarcástica, com julgamento pessoal
     

     View Slide

173. "Esse PR não pode ser mergeado"
     comentário opinativo, sem ação concreta, imperativo
     

     View Slide

174. "Esse PR não pode ser mergeado"
     comentário opinativo, sem ação concreta, imperativo
     

     View Slide

175. "Por que não criou uma nova classe?"
     pergunta com julgamento pessoal ainda
     "como você não pensou nisso?"
     

     View Slide

176. "Por que não criou uma nova classe?"
     pergunta com julgamento pessoal ainda
     "como você não pensou nisso?"
     

     View Slide

177. busque comentar
     de maneira construtiva
     

     View Slide

178. construtivo
     "O que você acha sobre extrair essa
     lógica para uma classe? Acredito que
     vai melhorar a legibilidade e reduzir a
     complexidade"
     

     View Slide

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?"
     

     View Slide

180. ...
     

     View Slide

181. DEFINIÇÃO
     PRÁTICAS DO
     DIA A DIA
     DESAFIOS
     APRENDIZADOS
     

     View Slide

182. DEFINIÇÃO
     PRÁTICAS DO
     DIA A DIA
     DESAFIOS
     APRENDIZADOS
     

     View Slide

183. desenvolvimento de software
     tem muito a ver com cultura e
     comunicação
     

     View Slide

184. "A cultura não faz as pessoas,
     as pessoas fazem a cultura"
     Chimamanda Ngozi Adichie
     

     View Slide

185. olhe para o seu time
     

     View Slide

186. diversidade ajuda a estimular empatia
     

     View Slide

187. pode ajudar a reduzir
     comportamentos tóxicos
     

     View Slide

188. e impactar positivamente
     na inovação e lucro
     

     View Slide

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
     

     View Slide

190. olhe também para o ambiente
     fatores não-técnicos
     

     View Slide

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.
     

     View Slide

192. a qualidade do software
     reflete todos esses fatores
     

     View Slide

193. impacta também no código escrito
     

     View Slide

194. código escrito é uma
     forma de comunicação
     

     View Slide

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

     View Slide

196. code review é sobre cultura,
     pessoas, qualidade de software
     

     View Slide

197. e aí, como é o code review
     no seu dia a dia?
     

     View Slide

198. ...
     

     View Slide

199. https://sourcelevel.io/code-review-ebook
     

     View Slide

200. ...
     

     View Slide

201. minhas referências
     

     View Slide

202. View Slide

203. View Slide

204. google.github.io/eng-practices/review/reviewer/standard.html
     

     View Slide

205. View Slide

206. View Slide

207. View Slide

208. View Slide

209. View Slide

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/
     

     View Slide

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
     

     View Slide

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
     

     View Slide

213. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
     

     View Slide

214. All the little things - Sandi Metz
     https://www.youtube.com/watch?v=8bZh5LMaSmE
     

     View Slide

215. ...
     

     View Slide

216. View Slide

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
     

     View Slide

218. ...
     

     View Slide

219. https://twitter.com/rla4/status/1097982806163185666
     

     View Slide

220. ...
     

     View Slide

221. railsgirls.com.br
     

     View Slide

222. View Slide

223. View Slide

224. View Slide

225. CARNIVAL EDITION
     

     View Slide

226. View Slide

227. speakerdeck.com/elainenaomi
     elainenaomi.dev
     Muito
     obrigada
     illustrations from undraw.co
     

     View Slide