O documento discute os desafios e práticas da revisão de código. Ele define code review como um processo de verificação de sistemas por meio da análise do código fonte por humanos e discute seus objetivos de identificar defeitos e melhorar a qualidade e manutenibilidade do código. Também aborda práticas como pair programming, pull requests e boas práticas para autores e revisores, além de desafios como alinhamento, diversidade e comportamentos tóxicos.

1. decodificando o
CODE REVIEW

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

3. careers.plataformatec.com.br

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

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

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

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

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

9. qual é o objetivo?

11. 2001

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

13. 2009

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

15. Dívida Técnica
Valor de negócio
Custodamudança
tempo
How to Monetize Application Technical Debt, Gartner, 2011

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

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

19. QUALIDADE DE SOFTWARE
Confiabilidade
Corretude
Eficiência
Manutenabilidade
Valor de negócio
https://en.wikipedia.org/wiki/Software_quality

20. ...

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

22. como fazer um code review?

23. como pessoa revisora

24. Pair Programming
Pull Request

25. Pair Programming
Pull Request

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

27. ...

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

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

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

32. revisão por meio de comentários

34. transferência de conhecimento
mentoria

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

36. boas práticas

37. como pessoa autora

38. Título explicativo
Motivação (contexto de negócio)
Lista de dúvidas e discussões prévias
Gifs, screenshots das alterações

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

40. Marcar pessoas como revisoras
Aplicar as alterações necessárias
Responder a todos os comentários

41. ...

42. como pessoa revisora

43. Identificar defeitos (bugs)
Sugerir soluções alternativas, refatorações
Reforçar padrões de código e design
Validar funcionalidade (código + negócio)

44. Identificar problemas de segurança
Analisar impactos na performance
Sugerir documentações
Validar a qualidade do código-fonte

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

46. ...

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

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

49. 2018

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

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

52. mágica?

53. alinhamento

54. Sua base de código parece ter sido
escrita por ÚNICA PESSOA?
SIM NÃO
Fonte: Talking with Tech Leads - Patrick Kua

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

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

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

58. como ir nessa direção?

59. ...

60. como pessoa

61. ...

62. lembre-se que o feedback
deve ser sobre o código,
e não sobre as pessoas

63. ninguém acorda e pensa:
vou lá adicionar um bug e já volto

64. ...

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

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

67. não é porque alguém é iniciante,
que não vai ter contribuição

68. ...

69. use comentários
explícitos e descritivos

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

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

73. ...

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

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

78. CÓDIGO: ELAINE
50% por 6 meses

79. ...

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

81. ...

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

83. não se limite à ferramenta de review

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

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

86. ...

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

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

89. ...

90. como organização

91. ...

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

93. ...

94. fator social

95. 2014

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

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

98. ...

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

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

102. comportamentos
tóxicos

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

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

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

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

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

108. como evitar isso?

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

110. ask, don't tell

111. ok, é só perguntar

112. ok, é só perguntar

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

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

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

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

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

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

119. busque comentar
de maneira construtiva

120. construtivo
"O que você acha sobre extrair essa
lógica para uma classe? Acredito que
vai melhorar a legibilidade e reduzir a
complexidade"

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

122. ...

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

124. desenvolvimento de software tem
muito a ver com cultura

125. "A cultura não faz as pessoas,
as pessoas fazem a cultura"
Chimamanda Ngozi Adichie

128. olhe para o seu time

129. diversidade ajuda a estimular empatia

130. pode ajudar a reduzir
comportamentos tóxicos

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

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

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

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

135. a qualidade do software
reflete todos esses fatores

136. impacta também no código escrito

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

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

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

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

141. minhas referências

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

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

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

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

155. muito obrigada
speakerdeck.com/elainenaomi
CÓDIGO: ELAINE
50% por 6 meses