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.

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
12. como fazer um code review?
13. Pair Programming Pull Request
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
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
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
38. processo de feedback
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
49. quem faz review, ajuda na construção da solução também
51. comportamentos tóxicos
53. podia ser pior? com certeza!
54. podia ser pior? com certeza!
55. mas, ainda sim, é super tóxico
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?"
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?
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
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
110. o que cultura tem a ver com tudo isso?
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.
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
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:
134. muito obrigada speakerdeck.com/elainenaomi