$30 off During Our Annual Pro Sale. View Details »

Decoding code review - Tech & Beers

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.

Elaine Naomi

April 27, 2022
Tweet

More Decks by Elaine Naomi

Other Decks in Programming

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

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

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

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

    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