Ada Lovelace Day - Decodificando o Code Review

Transcript

1. decodificando o CODE REVIEW

2. None

3. emilias.dainf.ct.utfpr.edu.br

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

   em Ciência da Computação (USP)

5. careers.plataformatec.com.br

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

12. None

13. 2001

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

15. 2009

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

17. Dívida Técnica Valor de negócio Custo da mudança tempo How

    to Monetize Application Technical Debt, Gartner, 2011
18. None

19. http://agilemodeling.com/essays/modelReviews.htm Desenv. custo da mudança tempo Requisitos Análise e Design

    Revisão Testes Produção

20. http://agilemodeling.com/essays/modelReviews.htm Desenv. custo da mudança tempo Requisitos Análise e Design

    Revisão Testes Produção

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

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

22. ...

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

24. como fazer um code review?

25. como pessoa revisora

26. Pair Programming Pull Request

27. Pair Programming Pull Request

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

29. ...

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

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

32. 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.
33. None

34. revisão por meio de comentários

35. None

36. transferência de conhecimento mentoria

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

38. boas práticas

39. como pessoa autora

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

    discussões prévias Gifs, screenshots das alterações

41. Mensagens de commits coerentes Código completo, testado Alterações pequenas Single

    responsibility principle

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

    todos os comentários

43. ...

44. como pessoa revisora

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

    código e design Validar funcionalidade (código + negócio)

46. Identificar problemas de segurança Analisar impactos na performance Sugerir documentações

    Validar a qualidade do código-fonte

47. Conhecer novas funcionalidades Aprender novas tecnologias Compartilhar conhecimento e dúvidas

48. ...

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

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

51. 2018

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

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

54. mágica?

55. alinhamento

56. google.github.io/eng-practices/review/reviewer/standard.html

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

    PESSOA? SIM NÃO Fonte: Talking with Tech Leads - Patrick Kua

58. collective code ownership https://martinfowler.com/bliki/CodeOwnership.html

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

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

61. como ir nessa direção?

62. ...

63. como pessoa

64. ...

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

    não sobre as pessoas

66. ninguém acorda e pensa: vou lá adicionar um bug e

    já volto

67. ...

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

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

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

    contribuição

71. ...

72. use comentários explícitos e descritivos

73. None

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

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

76. ...

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

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

79. None
80. None

81. ...

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

83. ...

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

85. não se limite à ferramenta de review

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

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

88. ...

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

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

    é prejudicial

91. ...

92. como organização

93. ...

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

95. ...

96. fator social

97. 2014

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

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

100. ...

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

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

103. None

104. comportamentos tóxicos

105. 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)

106. "como assim você não sabe isso???"

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

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

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

110. como evitar isso?

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

112. ask, don't tell

113. ok, é só perguntar

114. ok, é só perguntar

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

     pessoal

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

     pessoal

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

     concreta, imperativo

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

     concreta, imperativo

119. "Por que não criou uma nova classe?" pergunta com julgamento

     pessoal ainda "como você não pensou nisso?"

120. "Por que não criou uma nova classe?" pergunta com julgamento

     pessoal ainda "como você não pensou nisso?"

121. busque comentar de maneira construtiva

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

     uma classe? Acredito que vai melhorar a legibilidade e reduzir a complexidade"

123. 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?"

124. ...

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

126. desenvolvimento de software tem muito a ver com cultura

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

     cultura" Chimamanda Ngozi Adichie
128. None
129. None

130. olhe para o seu time

131. diversidade ajuda a estimular empatia

132. pode ajudar a reduzir comportamentos tóxicos

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

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

135. olhe também para o ambiente fatores não-técnicos

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

137. a qualidade do software reflete todos esses fatores

138. impacta também no código escrito

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

140. "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.

141. code review é sobre cultura, pessoas, qualidade de software

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

     a dia?

143. minhas referências

144. None
145. None
146. None
147. None
148. None
149. None
150. None
151. None

152. 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/

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

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

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

156. None

157. muito obrigada speakerdeck.com/elainenaomi