Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Decodificando o Code Review - Lovecoding 2022

Decodificando o Code Review - Lovecoding 2022

Elaine Naomi

October 07, 2022
Tweet

More Decks by Elaine Naomi

Other Decks in Programming

Transcript

  1. decodificando o CODE REVIEW LOVECODING - 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 Fotinho atualizada! RubyConf+ Brasil - setembro/2022
  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 Tech & Beers - Loft 2019 - 2022
  6. EXPECTATIVAS

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

  8. ...

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

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

  11. 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
  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. REVISÃO DE CÓDIGO 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
  14. REVISÃO DE CÓDIGO 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
  15. REVISÃO DE CÓDIGO 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. REVISÃO DE CÓDIGO 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
  17. None
  18. None
  19. qual é o objetivo?

  20. None
  21. 2001

  22. 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
  23. 2009

  24. 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
  25. 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
  26. como é a evolução de um software?

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

  28. ...

  29. None
  30. Dívida Técnica Custo da mudança Tempo How to Monetize Application

    Technical Debt, Gartner, 2011
  31. E é sobre isso e tá tudo bem

  32. e tudo bem mesmo faz parte

  33. mas e se a gente nunca olhar para essa dívida

    técnica?
  34. Valor de negócio Custo da mudança Tempo How to Monetize

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

    to Monetize Application Technical Debt, Gartner, 2011
  36. o processo de code review é uma forma de reduzir

    a dívida técnica
  37. costuma ter um custo menor de mudança em relação à

    correção de defeitos em produção
  38. http://agilemodeling.com/essays/modelReviews.htm Desenv. Custo da mudança Tempo Requisitos Análise e Design

    Revisão Testes Produção
  39. 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
  40. e pode impactar positivamente na qualidade de software

  41. QUALIDADE DE SOFTWARE Confiabilidade Corretude Eficiência Manutenabilidade Valor de negócio

    https://en.wikipedia.org/wiki/Software_quality
  42. é sobre impacto a longo prazo!

  43. é sobre impacto a longo prazo!

  44. ...

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

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

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

  48. Pair Programming Pull Request

  49. Pair Programming Pull Request

  50. Pair Programming Pull Request Merge Request or Change Request

  51. None
  52. documento sobre uma alteração

  53. título

  54. descrição

  55. pessoas revisoras

  56. revisão por meio de comentários

  57. None
  58. comparação do código atual com a alteração proposta

  59. None
  60. ...

  61. por que usar pull requests?

  62. Pair Programming Pull Request

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

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

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

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

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

    why, not the what
  68. ...

  69. 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.
  70. Trabalho Remoto

  71. ...

  72. transferência de conhecimento mentoria

  73. None
  74. visibilidade das alterações para outros times team awareness

  75. None
  76. ...

  77. boas práticas

  78. ...

  79. como pessoa autora

  80. Título explicativo Motivação (contexto de negócio) Lista de dúvidas e

    discussões prévias Gifs, screenshots das alterações
  81. Mensagens de commits coerentes Código completo, testado Alterações pequenas Single

    responsibility principle
  82. Revisar seu próprio PR Marcar pessoas como revisoras Aplicar as

    alterações necessárias Responder a todos os comentários
  83. Dica: Templates de Pull Requests

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

  85. ...

  86. como pessoa revisora

  87. Identificar defeitos (bugs) Sugerir soluções alternativas, refatorações Reforçar padrões de

    código e design Validar funcionalidade (código + negócio)
  88. Identificar problemas de segurança Analisar impactos na performance Sugerir documentações

    Validar a qualidade do código-fonte
  89. Conhecer novas funcionalidades Aprender novas tecnologias Compartilhar conhecimento e dúvidas

  90. ...

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

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

  93. ...

  94. None
  95. ...

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

  97. ...

  98. visibilidade

  99. Ferramentas para notificações de PRs Métricas de acompanhamento do projeto

    Monitoração de bugs
  100. ...

  101. impacto no tempo de entrega

  102. 2018

  103. 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
  104. 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
  105. mágica?

  106. alinhamento

  107. Sua base de código parece ter sido escrita por ÚNICA

    PESSOA? SIM NÃO Fonte: Talking with Tech Leads - Patrick Kua
  108. ...

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

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

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

  112. como ir nessa direção?

  113. ...

  114. como pessoa

  115. ...

  116. lembre-se que o feedback deve ser sobre o código, e

    não sobre as pessoas
  117. ninguém acorda e pensa: vou lá adicionar um bug e

    já volto
  118. ...

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

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

  121. não é porque alguém é iniciante, que não vai ter

    contribuição
  122. ...

  123. use comentários explícitos e descritivos

  124. None
  125. é para eu jogar fora a minha alteração?

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

  127. ...

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

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

  130. None
  131. None
  132. ...

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

  134. ...

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

  136. não se limite à ferramenta de review

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

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

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

  141. ...

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

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

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

    ou comportamento é prejudicial
  145. leia sobre comunicação não-violenta muitas vezes não é óbvio que

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

    um comentário ou comportamento é prejudicial
  147. ...

  148. como organização

  149. ...

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

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

  152. ...

  153. fator social

  154. 2014

  155. 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
  156. 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.
  157. ...

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

  159. Inclusive Language in Technology https://www.it.northwestern.edu/about/it-projects/dei/glossary.html

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

  161. None
  162. comportamentos tóxicos

  163. 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)
  164. "como assim você não sabe isso???"

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

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

  167. 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
  168. como evitar isso?

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

  170. ask, don't tell

  171. ok, é só perguntar

  172. ok, é só perguntar

  173. "Testes não são importantes pra você?" pergunta sarcástica, com julgamento

    pessoal
  174. "Testes não são importantes pra você?" pergunta sarcástica, com julgamento

    pessoal
  175. "Esse PR não pode ser mergeado" comentário opinativo, sem ação

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

    concreta, imperativo
  177. "Por que não criou uma nova classe?" pergunta com julgamento

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

    pessoal ainda "como você não pensou nisso?"
  179. busque comentar de maneira construtiva

  180. construtivo "O que você acha sobre extrair essa lógica para

    uma classe? Acredito que vai melhorar a legibilidade e reduzir a complexidade"
  181. 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?"
  182. ...

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

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

  185. desenvolvimento de software tem muito a ver com cultura e

    comunicação
  186. "A cultura não faz as pessoas, as pessoas fazem a

    cultura" Chimamanda Ngozi Adichie
  187. olhe para o seu time

  188. diversidade ajuda a estimular empatia

  189. pode ajudar a reduzir comportamentos tóxicos

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

  191. 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
  192. olhe também para o ambiente fatores não-técnicos

  193. 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.
  194. a qualidade do software reflete todos esses fatores

  195. impacta também no código escrito

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

  197. 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."
  198. code review é sobre cultura, pessoas, qualidade de software

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

    a dia?
  200. ...

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

  202. ...

  203. minhas referências

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

  207. None
  208. None
  209. None
  210. None
  211. None
  212. 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/

  213. 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
  214. 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
  215. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

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

  217. ...

  218. None
  219. 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

  220. ...

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

  222. ...

  223. railsgirls.com.br

  224. None
  225. None
  226. None
  227. CARNIVAL EDITION

  228. None
  229. speakerdeck.com/elainenaomi elainenaomi.dev Muito obrigada illustrations from undraw.co