RubyConf BR - Decodificando o Code Review

583e920a7e9238a1c21e923025f8f641?s=47 Elaine Naomi
November 28, 2019

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

Sala Codamos

583e920a7e9238a1c21e923025f8f641?s=128

Elaine Naomi

November 28, 2019
Tweet

Transcript

  1. RUBYCONF BRASIL 2019 decodificando o CODE REVIEW

  2. 1996

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

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

    em Ciência da Computação (USP) 2019 slides disponíveis
  5. plataformatec.com

  6. expectativas: discutir os desafios e práticas da revisão de código

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

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

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

  13. None
  14. ...

  15. mas na etapa de testes os erros vão aparecer...

  16. aí o código é revisado assim:

  17. None
  18. ...

  19. 2001

  20. 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. 2009

  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
  23. None
  24. Dívida Técnica Custo da mudança tempo How to Monetize Application

    Technical Debt, Gartner, 2011
  25. None
  26. Dívida Técnica Valor de negócio Custo da mudança tempo How

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

    essa dívida
  29. a etapa de revisão de código costuma ter um custo

    menor de mudança em relação a bugs em produção
  30. http://agilemodeling.com/essays/modelReviews.htm Desenv. custo da mudança tempo Requisitos Análise e Design

    Revisão Testes Produção
  31. 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
  32. e pode contribuir para aumentar a qualidade de software

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

    https://en.wikipedia.org/wiki/Software_quality
  34. ...

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

  36. como fazer um code review?

  37. como pessoa revisora

  38. Pair Programming Pull Request

  39. Pair Programming Pull Request

  40. None
  41. revisão por meio de comentários

  42. None
  43. None
  44. ...

  45. mas, atenção!

  46. às vezes os comentários podem gerar uma guerra

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

  48. sem spoilers, vamos chegar lá

  49. ...

  50. por que os pull requests podem ser interessantes?

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

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

  53. 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.
  54. transferência de conhecimento mentoria

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

  56. boas práticas

  57. como pessoa autora

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

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

    responsibility principle
  60. Marcar pessoas como revisoras Aplicar as alterações necessárias Responder a

    todos os comentários
  61. ...

  62. como pessoa revisora

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

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

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

  66. ...

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

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

  69. visibilidade

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

    Monitoração de bugs
  71. impacto no tempo de entrega

  72. 2018

  73. 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
  74. 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
  75. mágica?

  76. alinhamento

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

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

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

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

  81. como ir nessa direção?

  82. ...

  83. como pessoa

  84. ...

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

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

    já volto
  87. ...

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

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

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

    contribuição
  91. ...

  92. use comentários explícitos e descritivos

  93. None
  94. é para eu jogar fora a minha alteração?

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

  96. ...

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

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

  99. None
  100. None
  101. CÓDIGO: CODAMOS 100% por 12 meses

  102. None
  103. ...

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

  105. ...

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

  107. não se limite à ferramenta de review

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

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

  110. ...

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

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

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

    ou comportamento é prejudicial
  114. ...

  115. como organização

  116. ...

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

  118. ...

  119. fator social

  120. 2014

  121. 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
  122. 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.
  123. ...

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

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

  126. None
  127. comportamentos tóxicos

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

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

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

  132. 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
  133. como evitar isso?

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

  135. ask, don't tell

  136. ok, é só perguntar

  137. ok, é só perguntar

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

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

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

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

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

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

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

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

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

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

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

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

    cultura" Chimamanda Ngozi Adichie
  151. None
  152. None
  153. olhe para o seu time

  154. diversidade ajuda a estimular empatia

  155. pode ajudar a reduzir comportamentos tóxicos

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

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

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

  161. impacta também no código escrito

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

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

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

    a dia?
  166. minhas referências

  167. None
  168. None
  169. google.github.io/eng-practices/review/reviewer/standard.html

  170. None
  171. None
  172. None
  173. None
  174. None
  175. None
  176. 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/

  177. 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
  178. 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
  179. Plataformatec Inside - Novidades do Rails 6 https://www.youtube.com/watch?v=FtZyxCPx-i8

  180. Plataformatec Inside www.youtube.com/user/plataformatectv dia 11/12 às 19h

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

  182. railsgirls.com.br

  183. muito obrigada elainenaomi.dev CÓDIGO: CODAMOS 100% por 12 meses