Guru SP: Decodificando o code review

Guru SP: 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.

583e920a7e9238a1c21e923025f8f641?s=128

Elaine Naomi

June 29, 2019
Tweet

Transcript

  1. decodificando o CODE REVIEW

  2. Desenvolvedora de Software (Plataformatec) Mestre em Ciência da Computação (USP)

    Elaine Naomi Watanabe github.com/elainenaomi twitter.com/elaine_nw
  3. expectativas: discutir os desafios e práticas da revisão de código

  4. 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
  5. 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
  6. qual é o objetivo?

  7. None
  8. 2001

  9. 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
  10. http://agilemodeling.com/essays/modelReviews.htm Desenv. custo da mudança tempo Requisitos Análise e Design

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

    Revisão Testes Produção
  12. QUALIDADE DE SOFTWARE Confiabilidade Corretude Eficiência Manutenabilidade Valor de negócio

    https://en.wikipedia.org/wiki/Software_quality
  13. Dívida Técnica Valor de negócio Custo da mudança tempo How

    to Monetize Application Technical Debt, Gartner, 2011
  14. 2009

  15. 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
  16. como fazer um code review?

  17. como pessoa revisora

  18. Pair Programming Pull Request

  19. Pair Programming Pull Request

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

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

  22. 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.
  23. None
  24. revisão por meio de comentários

  25. None
  26. visibilidade das alterações para outros times team awareness

  27. transferência de conhecimento mentoria

  28. boas práticas

  29. ...

  30. como pessoa autora

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

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

    responsibility principle
  33. marque pessoas como revisoras

  34. aplique as alterações necessárias

  35. e responda a todos os comentários

  36. ...

  37. como pessoa revisora

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

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

    Validar a qualidade do código-fonte
  40. não esqueça é importante que os comentários sejam explícitos e

    descritivos
  41. None
  42. é para eu jogar fora a minha alteração?

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

  44. o feedback deve ser sobre o código, e não sobre

    as pessoas
  45. quem faz review, ajuda na construção da solução também collective

    code ownership
  46. além disso

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

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

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

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

  51. não se limite à ferramenta de review

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

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

  54. ...

  55. como organização

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

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

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

  59. ...

  60. fator social

  61. 2014

  62. 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 incluso, o PR tem 17% mais chance de ser aceito fator técnico
  63. 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.
  64. PRs com grandes quantidades de comentários, têm chance menor de

    ser aceito no contexto open source 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.
  65. None
  66. comportamentos tóxicos

  67. None
  68. podia ser pior? com certeza!

  69. podia ser pior? com certeza!

  70. mas, ainda sim, é super tóxico

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

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

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

  75. "Sentiment analysis on comments has provided evidence that comments with

    negative tone are less likely to be useful" 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
  76. como evitar isso?

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

  78. ask, don't tell

  79. ok, é só perguntar

  80. ok, é só perguntar

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

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

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

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

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

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

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

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

    uma classe? Acredito que vai melhorar a legibilidade e reduzir a complexidade"
  89. 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?"
  90. software é também sobre cultura

  91. "A cultura não faz as pessoas, as pessoas fazem a

    cultura" Chimamanda Ngozi Adichie
  92. olhe para a diversidade do seu time

  93. diversidade ajuda a estimular empatia

  94. pode ajudar a reduzir comportamentos tóxicos

  95. e impacta positivamente na inovação e lucro

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

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

  100. impacta também no código escrito

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

  102. "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.
  103. e aí, como está a qualidade do seu software?

  104. minhas referências

  105. None
  106. None
  107. None
  108. None
  109. None
  110. None
  111. None
  112. None
  113. 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/

  114. 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 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
  115. None
  116. muito obrigada speakerdeck.com/elainenaomi