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

Code review: o que isso diz sobre a cultura dos times de desenvolvimento?

Code review: o que isso diz sobre a cultura dos times de desenvolvimento?

Como é o processo de desenvolvimento de software em sua empresa? Existe o foco na qualidade do software desenvolvido ou apenas na funcionalidade entregue? Como é a comunicação e interação dos times de desenvolvimento? Quais são as práticas adotadas para melhorar esses pontos?
Nessa palestra, vamos discutir sobre a cultura da revisão de código, analisando o impacto e importância na entrega de software com qualidade e na construção de times distribuídos.

583e920a7e9238a1c21e923025f8f641?s=128

Elaine Naomi

April 14, 2019
Tweet

Transcript

  1. code review o que isso diz sobre a cultura dos

    times de desenvolvimento?
  2. Elaine Naomi Watanabe Desenvolvedora de Software (Plataformatec) Mestre em Ciência

    da Computação (USP) twitter.com/elaine_nw speakerdeck.com/elainenaomi
  3. careers.plataformatec.com.br

  4. expectativa discutir desafios e boas práticas de code review

  5. 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
  6. 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
  7. pelo menos um dos humanos não pode ter alterado o

    código em revisão importante
  8. por que precisamos disso?

  9. garantia de qualidade processo que visa a criação de softwares

    confiáveis, corretos e com valor de negócio https://en.wikipedia.org/wiki/Software_quality
  10. http://agilemodeling.com/essays/modelReviews.htm Desenv. custo da mudança tempo Requisitos Análise e Design

    Revisão Testes Produção
  11. None
  12. como fazer um code review?

  13. Pair Programming Pull Request

  14. None
  15. Pair Programming Pull Request

  16. 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.
  17. 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.
  18. Pair Programming Pull Request código + contexto de negócio

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

  20. boas práticas

  21. como pessoa autora

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

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

    responsibility principle Pull requests
  25. como pessoa revisora

  26. como pessoa revisora

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

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

    Validação da qualidade do código-fonte Pull requests
  30. Código fácil de ler Código fácil de entender Código fácil

    de manter Código de qualidade
  31. Código fácil de ler Código fácil de entender Código fácil

    de manter Código de qualidade
  32. Dívida Técnica Valor de negócio Custo da mudança Tempo How

    to Monetize Application Technical Debt, Gartner, 2011
  33. outros aspectos importantes

  34. informar outros times sobre as alterações team awareness

  35. transferência de conhecimento mentoria

  36. None
  37. None
  38. processo de feedback

  39. None
  40. processo de feedback textual

  41. cuidado com possíveis equívocos

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

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

  44. cuidado para não levar para o lado pessoal

  45. o feedback é sobre o código, e não sobre as

    pessoas
  46. é importante comentários mais explícitos, descritivos

  47. collective code ownership

  48. None
  49. quem faz review, ajuda na construção da solução também

  50. None
  51. comportamentos tóxicos

  52. None
  53. podia ser pior? com certeza!

  54. podia ser pior? com certeza!

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

  56. None
  57. 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)
  58. "como assim você não sabe isso???"

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

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

  61. como evitar isso?

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

  63. ask, don't tell

  64. ok, é só perguntar

  65. ok, é só perguntar

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

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

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

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

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

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

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

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

    uma classe? Acredito que vai melhorar a legibilidade e reduzir a complexidade"
  74. 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?"
  75. None
  76. "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
  77. os conflitos na equipe vão acabar?

  78. None
  79. conflitos podem acontecer ainda

  80. porque discordar não é um problema

  81. cuidado com comentários não-relacionados à entrega

  82. por exemplo

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

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

  85. None
  86. None
  87. melhorias de design podem ser entregues em outro pull request

  88. além disso

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

  90. não se limite à ferramenta de review

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

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

  93. comente sempre de maneira concisa e amigável

  94. justifique suas sugestões

  95. liste formas de resolver os problemas

  96. se possível, com exemplos de código

  97. e isso vale para todas as pessoas envolvidas!

  98. justifique se uma sugestão não for aplicada

  99. responda todos os comentários

  100. preste atenção na forma como você se comunica com seu

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

    é prejudicial
  102. exercite a empatia

  103. e como organização?

  104. dê visibilidade sobre o processo de code review

  105. preste atenção na forma como seu time se comunica

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

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

  108. estimule um ambiente colaborativo

  109. None
  110. o que cultura tem a ver com tudo isso?

  111. None
  112. None
  113. "A cultura não faz as pessoas, as pessoas fazem a

    cultura" Chimamanda Ngozi Adichie
  114. por isso, cuidado com comportamentos tóxicos

  115. promova diversidade

  116. diversidade ajuda a estimular empatia

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

  118. 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
  119. o ambiente também importa fatores não-técnicos

  120. 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.
  121. None
  122. times mais colaborativos, softwares melhores

  123. "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.
  124. minhas referências

  125. None
  126. None
  127. None
  128. None
  129. None
  130. None
  131. 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/ Mais referências:

  132. 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 Mais referências:
  133. None
  134. muito obrigada speakerdeck.com/elainenaomi