O documento discute os benefícios e melhores práticas da revisão de código. A revisão de código é um processo importante para identificar defeitos e melhorar a qualidade do software. Fatores técnicos e sociais influenciam o resultado da revisão. Comportamentos tóxicos devem ser evitados em favor de comentários construtivos.

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?

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.
custodamudança
tempo
Requisitos
Análise e
Design
Revisão Testes Produção

11. http://agilemodeling.com/essays/modelReviews.htm
Desenv.
custodamudanç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
Custodamudanç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.

24. revisão por meio de comentários

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

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.

66. comportamentos
tóxicos

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

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

116. muito obrigada
speakerdeck.com/elainenaomi