Guru SP: Decodificando o code review

Slide 1

Slide 1 text

decodificando o CODE REVIEW

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

expectativas: discutir os desaﬁos e práticas da revisão de código

Slide 4

Slide 4 text

https://en.wikipedia.org/wiki/Code_review CODE REVIEW processo de veriﬁcação de um sistema por meio da análise do código fonte, realizada por humanos

Slide 5

Slide 5 text

https://en.wikipedia.org/wiki/Code_review CODE REVIEW processo de veriﬁcação de um sistema por meio da análise do código fonte, realizada por humanos

Slide 6

Slide 6 text

qual é o objetivo?

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

2001

Slide 9

Slide 9 text

60% dos defeitos podem ser identiﬁcados na revisão do código Boehm, Barry, and Victor R. Basili. "Top 10 list [software development]." Computer 34.1 (2001): 135-137

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

QUALIDADE DE SOFTWARE Conﬁabilidade Corretude Eﬁciência Manutenabilidade Valor de negócio https://en.wikipedia.org/wiki/Software_quality

Slide 13

Slide 13 text

Dívida Técnica Valor de negócio Custo da mudança tempo How to Monetize Application Technical Debt, Gartner, 2011

Slide 14

Slide 14 text

2009

Slide 15

Slide 15 text

Revisão de código é uma boa ferramenta para identiﬁcar defeitos relacionados à evolutibilidade do código que não são identiﬁcá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

Slide 16

Slide 16 text

como fazer um code review?

Slide 17

Slide 17 text

como pessoa revisora

Slide 18

Slide 18 text

Pair Programming Pull Request

Slide 19

Slide 19 text

Pair Programming Pull Request

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

revisão por meio de comentários

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

visibilidade das alterações para outros times team awareness

Slide 27

Slide 27 text

transferência de conhecimento mentoria

Slide 28

Slide 28 text

boas práticas

Slide 29

Slide 29 text

...

Slide 30

Slide 30 text

como pessoa autora

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

marque pessoas como revisoras

Slide 34

Slide 34 text

aplique as alterações necessárias

Slide 35

Slide 35 text

e responda a todos os comentários

Slide 36

Slide 36 text

...

Slide 37

Slide 37 text

como pessoa revisora

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Identiﬁcar problemas de segurança Analisar impactos na performance Sugerir documentações Validar a qualidade do código-fonte

Slide 40

Slide 40 text

não esqueça é importante que os comentários sejam explícitos e descritivos

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

o feedback deve ser sobre o código, e não sobre as pessoas

Slide 45

Slide 45 text

quem faz review, ajuda na construção da solução também collective code ownership

Slide 46

Slide 46 text

além disso

Slide 47

Slide 47 text

comentários repetitivos sobre estilo de código

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

melhorias de design podem ser entregues em outro pull request

Slide 50

Slide 50 text

se chegar a uma conclusão estiver difícil

Slide 51

Slide 51 text

não se limite à ferramenta de review

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

documente as decisões e discussões oﬄine

Slide 54

Slide 54 text

...

Slide 55

Slide 55 text

como organização

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

...

Slide 60

Slide 60 text

fator social

Slide 61

Slide 61 text

2014

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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.

Slide 64

Slide 64 text

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.

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

comportamentos tóxicos

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

podia ser pior? com certeza!

Slide 69

Slide 69 text

podia ser pior? com certeza!

Slide 70

Slide 70 text

mas, ainda sim, é super tóxico

Slide 71

Slide 71 text

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)

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

"como deixaram você entrar aqui??"

Slide 74

Slide 74 text

"vou ter que te explicar de novo?"

Slide 75

Slide 75 text

"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

Slide 76

Slide 76 text

como evitar isso?

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

ask, don't tell

Slide 79

Slide 79 text

ok, é só perguntar

Slide 80

Slide 80 text

ok, é só perguntar

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

busque comentar de maneira construtiva

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

software é também sobre cultura

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

olhe para a diversidade do seu time

Slide 93

Slide 93 text

diversidade ajuda a estimular empatia

Slide 94

Slide 94 text

pode ajudar a reduzir comportamentos tóxicos

Slide 95

Slide 95 text

e impacta positivamente na inovação e lucro

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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.

Slide 99

Slide 99 text

a qualidade do software reﬂete todos esses fatores

Slide 100

Slide 100 text

impacta também no código escrito

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

e aí, como está a qualidade do seu software?

Slide 104

Slide 104 text

minhas referências

Slide 105

Slide 105 text

No content

Slide 106

Slide 106 text

No content

Slide 107

Slide 107 text

No content

Slide 108

Slide 108 text

No content

Slide 109

Slide 109 text

No content

Slide 110

Slide 110 text

No content

Slide 111

Slide 111 text

No content

Slide 112

Slide 112 text

No content

Slide 113

Slide 113 text

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/

Slide 114

Slide 114 text

Building an Iconic Company - Reed Hasting youtube.com/watch?v=BsXXIfqbnRk A Arquitetura (Peculiar) do Stack Overﬂow - Roberta Arcoverde infoq.com/br/presentations/a-arquitetura-peculiar-do-stack-overﬂow 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