Decodificando o Code Review - Webinar

Decodificando o Code Review - Webinar

583e920a7e9238a1c21e923025f8f641?s=128

Elaine Naomi

March 27, 2020
Tweet

Transcript

  1. SOURCELEVEL WEBINAR - 2020 decodificando o CODE REVIEW

  2. 1996

  3. twitter.com/elaine_nw elainenaomi.dev Elaine Naomi Watanabe Desenvolvedora de Software (The RealReal)

    Mestrado em Ciência da Computação (USP) 2020
  4. twitter.com/elaine_nw elainenaomi.dev Elaine Naomi Watanabe Desenvolvedora de Software (The RealReal)

    Mestrado em Ciência da Computação (USP) slides disponíveis 2020
  5. twitter.com/elaine_nw elainenaomi.dev Elaine Naomi Watanabe Desenvolvedora de Software (The RealReal)

    Mestrado em Ciência da Computação (USP) versão empreendedora 2020
  6. por onde esta palestra andou? Agile Trends The DevConf -

    São Paulo GURU SP Ada Lovelace Day - Curitiba Rubyconf Brasil - Trilha Codamos 2019
  7. expectativas discutir os desafios e práticas da revisão de código

  8. definição práticas do dia a dia desafios aprendizados

  9. definição práticas do dia a dia desafios aprendizados

  10. 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
  11. None
  12. None
  13. qual é o objetivo?

  14. None
  15. 2001

  16. 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
  17. 2009

  18. 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
  19. capacidade de adaptação ao longo do tempo 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
  20. como é essa evolução?

  21. e sempre é tranquilo alterar a base de código?

  22. ...

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

    Technical Debt, Gartner, 2011
  25. None
  26. e tudo bem mesmo faz parte

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

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

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

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

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

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

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

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

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

  37. ...

  38. aprendizados definição práticas do dia a dia desafios

  39. como fazer um code review?

  40. Pair Programming Pull Request

  41. Pair Programming Pull Request

  42. None
  43. documento sobre uma alteração

  44. título

  45. descrição

  46. pessoas revisoras

  47. revisão por meio de comentários

  48. None
  49. comparação do código atual com a alteração proposta

  50. None
  51. ...

  52. por que usar pull requests?

  53. Pair Programming Pull Request

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

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

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

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

    why, not the what
  58. 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.
  59. trabalho remoto

  60. fique em casa, se possível trabalho remoto

  61. ...

  62. transferência de conhecimento mentoria

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

  64. ...

  65. boas práticas

  66. ...

  67. como pessoa autora

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

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

    responsibility principle
  70. Revisar seu PR =D Marcar pessoas como revisoras Aplicar as

    alterações necessárias Responder a todos os comentários o que mais posso fazer?
  71. Dica: Templates de Pull Requests

  72. help.github.com/pt/github/creating-cloning-and-archiving-repositories/creating-a-template-repository

  73. ...

  74. como pessoa revisora

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

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

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

  78. ...

  79. definição práticas do dia a dia desafios aprendizados

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

  81. ...

  82. None
  83. ...

  84. visibilidade

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

    Monitoração de bugs
  86. ...

  87. impacto no tempo de entrega

  88. 2018

  89. 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
  90. 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
  91. mágica?

  92. alinhamento

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

    PESSOA? SIM NÃO Fonte: Talking with Tech Leads - Patrick Kua
  94. collective code ownership https://martinfowler.com/bliki/CodeOwnership.html

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

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

  97. como ir nessa direção?

  98. ...

  99. como pessoa

  100. ...

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

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

    já volto
  103. ...

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

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

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

    contribuição
  107. ...

  108. use comentários explícitos e descritivos

  109. None
  110. é para eu jogar fora a minha alteração?

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

  112. ...

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

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

  115. None
  116. None
  117. None
  118. ...

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

  120. ...

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

  122. não se limite à ferramenta de review

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

  124. videoconferência presencialmente http://blog.plataformatec.com.br/2018/11/trabalhando-com-times-distribuidos/ por favor, só depois da quarentena!

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

  126. ...

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

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

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

    ou comportamento é prejudicial
  130. ...

  131. como organização

  132. ...

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

  134. ...

  135. fator social

  136. 2014

  137. 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
  138. 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.
  139. ...

  140. formalize as recomendações, crie guidelines sobre aspectos comportamentais

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

  142. None
  143. comportamentos tóxicos

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

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

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

  148. 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
  149. como evitar isso?

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

  151. ask, don't tell

  152. ok, é só perguntar

  153. ok, é só perguntar

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

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

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

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

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

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

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

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

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

  164. definição práticas do dia a dia desafios aprendizados

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

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

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

  168. diversidade ajuda a estimular empatia

  169. pode ajudar a reduzir comportamentos tóxicos

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

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

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

  175. impacta também no código escrito

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

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

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

    a dia?
  180. minhas referências

  181. None
  182. None
  183. google.github.io/eng-practices/review/reviewer/standard.html

  184. None
  185. None
  186. None
  187. None
  188. None
  189. None
  190. 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/

  191. 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
  192. 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
  193. https://twitter.com/rla4/status/1097982806163185666

  194. railsgirls.com.br

  195. elixirbrasil.com 2 8 / 2 9 N O V E

    M B R 0
  196. twitter.com/elaine_nw elainenaomi.dev muito obrigada