Transferir como PDF, PPTX
![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](https://image.slidesharecdn.com/gurusp-codereview6-190918134649/85/Guru-SP-Decodificando-o-code-review-9-320.jpg)
Carregado porElaine Naomi
Guru SP: Decodificando o code review
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.
Mais conteúdo relacionado
![Ctfl 2018 sample_b[v1.3br]](https://cdn.slidesharecdn.com/ss_thumbnails/ctfl2018samplebv1-210928210422-thumbnail.jpg?width=640&height=640&fit=bounds)
Semelhante a Guru SP: Decodificando o code review
Guru SP: Decodificando o code review
- 1.
- 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 desafiose práticas da revisão de código
- 4. https://en.wikipedia.org/wiki/Code_review CODE REVIEW processo deverificaçã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 deverificação de um sistema por meio da análise do código fonte, realizada por humanos
- 6. qual é oobjetivo?
- 8.
- 9. 60% dos defeitospodem 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.
- 11.
- 12. QUALIDADE DE SOFTWARE Confiabilidade Corretude Eficiência Manutenabilidade Valorde negócio https://en.wikipedia.org/wiki/Software_quality
- 13. Dívida Técnica Valor denegócio Custodamudança tempo How to Monetize Application Technical Debt, Gartner, 2011
- 14.
- 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 umcode review?
- 17.
- 18.
- 19.
- 20. Pair Programming Pull Request código+ contexto de negócio
- 21. Pair Programming Pull Request históricoacessível das discussões
- 22. interação assíncrona distribuída Mesmo local Mesmo tempo Tempodiferente 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 meiode comentários
- 26. visibilidade das alterações paraoutros times team awareness
- 27.
- 28.
- 29.
- 30.
- 31. Título explicativo Motivação (contextode negócio) Lista de dúvidas e discussões prévias Gifs, screenshots das alterações
- 32. Mensagens de commitscoerentes Código completo, testado Alterações pequenas Single responsibility principle
- 33. marque pessoas comorevisoras
- 34. aplique as alteraçõesnecessárias
- 35. e responda atodos os comentários
- 36.
- 37.
- 38. Identificar defeitos (bugs) Sugerirsoluções alternativas, refatorações Reforçar padrões de código e design Validar funcionalidade (código + negócio)
- 39. Identificar problemas desegurança Analisar impactos na performance Sugerir documentações Validar a qualidade do código-fonte
- 40. não esqueça é importanteque os comentários sejam explícitos e descritivos
- 42. é para eujogar fora a minha alteração?
- 43. ah, era sópara apagar o espaço extra
- 44. o feedback deveser 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.
- 47. comentários repetitivos sobre estilode código
- 48. podem ser substituídospor uma ferramenta de análise de código
- 49. melhorias de designpodem ser entregues em outro pull request
- 50. se chegar auma conclusão estiver difícil
- 51. não se limiteà ferramenta de review
- 52.
- 53. documente as decisõese discussões offline
- 54.
- 55.
- 56. tenha critérios bemdefinidos ex.: o número mínimo de aprovações
- 57. formalize as recomendações, crieguidelines sobre aspectos comportamentais
- 58. comunicação verbal, não verbale escrita
- 59.
- 60.
- 61.
- 62. Tsay, Jason, LauraDabbish, 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 pessoaautora 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 grandesquantidades 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.
- 68. podia ser pior? comcerteza!
- 69. podia ser pior? comcerteza!
- 70. mas, ainda sim, ésuper tóxico
- 71. COMPORTAMENTOS TÓXICOS https://medium.com/@jgefroh/toxic-developers-considered-harmful-f7ea1494d4c0 Impedem inovaçõese 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 quete explicar de novo?"
- 75. "Sentiment analysis oncomments 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.
- 77. Faça reviews comoseres humanos https://mtlynch.io/human-code-reviews-1/ https://mtlynch.io/human-code-reviews-2/
- 78.
- 79. ok, é sóperguntar
- 80. ok, é sóperguntar
- 81. "Testes não sãoimportantes pra vc?" pergunta sarcástica, com julgamento pessoal
- 82. "Testes não sãoimportantes pra vc?" pergunta sarcástica, com julgamento pessoal
- 83. "Esse PR nãopode ser mergeado" comentário opinativo, sem ação concreta, imperativo
- 84. "Esse PR nãopode ser mergeado" comentário opinativo, sem ação concreta, imperativo
- 85. "Por que nãocriou uma nova classe?" pergunta com julgamento pessoal ainda "como você não pensou nisso?"
- 86. "Por que nãocriou uma nova classe?" pergunta com julgamento pessoal ainda "como você não pensou nisso?"
- 87. busque comentar de maneiraconstrutiva
- 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, tomde 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émsobre cultura
- 91. "A cultura nãofaz as pessoas, as pessoas fazem a cultura" Chimamanda Ngozi Adichie
- 92. olhe para adiversidade do seu time
- 93. diversidade ajuda aestimular empatia
- 94. pode ajudar areduzir comportamentos tóxicos
- 95. e impacta positivamente nainovaçã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 parao ambiente fatores não-técnicos
- 98. pressão, sobrecarga deatividades, 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 dosoftware reflete todos esses fatores
- 100. impacta também nocódigo escrito
- 101. código escrito éuma forma de comunicação
- 102. "Instead of imaginingthat 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í, comoestá a qualidade do seu software?
- 104.
- 113.
- 114. Building an IconicCompany - 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.