Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada Bacharelado em Engenharia de Software
Please Review: Um feed de solicitações de
revisão de código integrado ao GitHub
José Bernardo Gurgel de Faria Filho
Natal - RN Novembro 2017
José Bernardo Gurgel de Faria Filho
Please Review: Um feed de solicitações de revisão de
código integrado ao GitHub
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte como requisito parcial para a ob-tenção do grau de bacharel em Engenharia de Software.
Orientador
Prof. Dr. Fernando Marques Figueira Filho
Universidade Federal do Rio Grande do Norte – UFRN Departamento de Informática e Matemática Aplicada – DIMAp
Natal-RN Novembro de 2017
Universidade Federal do Rio Grande do Norte – UFRN Sistema de Bibliotecas - SISBI
Catalogação da Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Faria Filho, José Bernardo Gurgel de.
Please Review: um feed de solicitações de revisão de código integrado ao GitHub / José Bernardo Gurgel de Faria Filho. - 2017.
42 f.: il.
Monografia (graduação) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Bacharelado em Engenharia de Software. Natal, RN, 2017.
Orientador: Fernando Marques Figueira Filho.
1. Engenharia de software – Monografia. 2. Revisão de código – Monografia. 3. Feed – Monografia. 4. Desenvolvimento de software – Monografia. 5. Awareness – Monografia. I. Figueira Filho, Fernando Marques. II. Título.
Monografia de Graduação sob o título Please Review: Um feed de solicitações de revisão de código integrado ao GitHub apresentada por José Bernardo Gurgel de Faria Filho e aceita pelo Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Prof. Dr. Fernando Marques Figueira Filho
Orientador
Departamento de Informática e Matemática Aplicada UFRN
Profa. Dra. Márcia Jacyntha Nunes Rodrigues Lucena
Departamento de Informática e Matemática Aplicada UFRN
Prof. Dr. Gibeon Soares De Aquino Junior
Departamento de Informática e Matemática Aplicada UFRN
À todos que me apoiaram ao longo desta caminhada: À minha família, Rosário , Gurgel e Isabel, por todo apoio, dedicação e carinho. À minha companheira de vida Aline, por sua paciência, amor e motivação do dia-a-dia.
Agradecimentos
Ao longo dessa jornada, tive a sorte de ter o apoio de muitas pessoas. Eu sou eterna-mente grato por isto.
Gostaria de agradecer aos meus pais que sempre me apoiaram em todas as etapas da vida. Obrigado por toda dedicação e carinho.
Agradeço à minha companheira Aline, pelas motivações que encontramos todos os dias. Obrigado pela sua atenção, paciência e apoio nas melhores e piores momentos. Você tornou tudo mais fácil.
Também quero agradecer à encerrada 4Soft e todos os seus ex-integrantes, por todo o aprendizado que tivemos juntos. Costumo dizer que a base do meu conhecimento foram as experiências que tive nesta empresa júnior.
Não posso deixar de agradecer a amizade dos meus amigos do curso de Engenharia de Software: Andreza, Iago, Igor, Jonathan, Lucas, Thiago, Rogério, Waldyr e especialmente em memória de Rafael, quem me ensinou tanto sobre desenvolvimento de software.
Please Review: Um feed de solicitações de revisão de
código integrado ao GitHub
Autor: José Bernardo Gurgel de Faria Filho Orientador: Prof. Dr. Fernando Marques Figueira Filho
Resumo
Revisão de código é uma prática da engenharia de software bastante comum em orga-nizações privativas e open source. Além de ser um método eficiente na detecção de defeitos, seu uso traz outros importantes benefícios ao time de desenvolvedores, como a transferên-cia de conhecimento e o aumento da awareness. Ferramentas podem auxiliar o processo de revisão de código, e seu uso pode trazer melhorias na qualidade e na quantidade de revisões.
O GitHub é a maior plataforma de repositório de código do mundo, e é a escolha de muitas organizações open source e privativas. A plataforma dispõe de uma eficiente ferramenta para revisões de código, em contra partida carece de uma maneira prática de visualizar os códigos que precisam de revisão. Este trabalho introduz uma ferramenta integrada ao GitHub, capaz de centralizar solicitações de revisão de código em um único canal de informação, produzindo um feed de solicitações de revisão de código que traz maior visibilidade às solicitações, consequentemente melhorando o processo de revisão de código dentro de uma organização.
Please Review: A review request feed integrated with
GitHub
Author: José Bernardo Gurgel de Faria Filho Advisor: Prof. Dr. Fernando Marques Figueira Filho
Abstract
Peer code review is a software engineering practice quite common in private and open source organizations. In addition to being an efficient method for detecting defects, its use brings other important benefits to the development team, such as knowledge transfer and the team awareness. Automated tools can help the code review process, and their use can bring improvements regarding the quality and quantity of revisions.
GitHub is the largest code repository platform in the world, and it’s the choice of many open source and private organizations. It has an efficient code review tool, but it lacks good ways of visualize code changes that need reviews. This paper introduces a tool integrated with GitHub capable of centralize code review requests in an unique channel, producing a feed of code review requests that brings more visability and to these requests, which results in a better code review process inside an organization.
Lista de figuras
1 Ferramenta de revisão de código do GitHub . . . p. 19 2 Exemplo de solicitação de revisão de código no GitHub . . . p. 19 3 Ferramenta de revisão de código do Gerrit . . . p. 20 4 Lista de mudanças de código no Gerrit . . . p. 20 5 Exemplo de solicitação de revisão no Stack Exchange . . . p. 21 6 Exemplo de revisão no StackExchange Code Review . . . p. 22 7 Desenvolvedor solicitando diretamente uma revisão de código à um outro
desenvolvedor através da aplicação de mensagens de texto . . . p. 23 8 Tela de login . . . p. 26 9 Cadastro de solicitação de revisão de código . . . p. 27 10 Visualização da solicitação de revisão . . . p. 28 11 Ferramenta de revisão de código do GitHub . . . p. 29 12 Confirmação de encerramento da solicitação de revisão . . . p. 29 13 Sessão do usuário . . . p. 30 14 Primeira pergunta. Respostas em escala: 1 - difícil; 5 - fácil. . . p. 31 15 Segunda pergunta. Respostas em escala: 1 - difícil; 5 - fácil. . . p. 32 16 Terceira pergunta. Respostas em escala: 1 - Não útil; 5 - Útil. . . p. 32 17 Quarta pergunta. Respostas em escala: 1 - Ineficiente; 5 - Eficiente. . . p. 33
Sumário
1 Introdução p. 12
1.1 Objetivos e Perguntas da Pesquisa . . . p. 13 1.2 Casos de uso da ferramenta . . . p. 13 1.2.1 Cadastro de uma solicitação de revisão . . . p. 14 1.2.2 Visualização de Feed . . . p. 14 1.2.3 Fechamento da solicitação de revisão . . . p. 14 1.3 Estrutura do trabalho . . . p. 14
2 Fundamentação Teórica p. 15
2.1 Revisão de Código . . . p. 15 2.1.1 Cinco lições de projetos open source . . . p. 15 2.1.1.1 Revisões Assíncronas . . . p. 15 2.1.1.2 Revisões Frequentes . . . p. 16 2.1.1.3 Revisões Incrementais . . . p. 16 2.1.1.4 Revisores especialistas . . . p. 16 2.1.1.5 Empoderamento dos revisores . . . p. 16 2.2 Feed de informação . . . p. 17 2.3 Awareness . . . p. 17
3 Metodologia p. 18
3.1 Estudo de ferramentas existentes . . . p. 18 3.1.1 GitHub . . . p. 18
3.1.2 Gerrit . . . p. 20 3.1.3 Stack Exchange: Code Review . . . p. 21 3.2 Estudo de caso . . . p. 22 3.2.1 Contexto da Empresa Alpha . . . p. 22 3.2.2 Coleta e análise de dados . . . p. 24
4 Definição e implementação de requisitos p. 25 4.1 Definição de Requisitos . . . p. 25 4.1.1 Funcionalidades . . . p. 26 4.1.1.1 Autenticar-se usando conta do GitHub . . . p. 26 4.1.1.2 Cadastrar solicitação de revisão a partir de pull request p. 27 4.1.1.3 Visualizar solicitação de revisão . . . p. 27 4.1.1.4 Abrir ferramenta de revisão de código do GitHub . . . p. 28 4.1.1.5 Encerramento de solicitação de revisão . . . p. 29 4.1.1.6 Fechar sessão . . . p. 30 4.1.2 Implementação . . . p. 30
5 Análise e discussão dos resultados p. 31 5.1 Respostas do questionário . . . p. 31 5.1.1 O quão difícil é o uso da ferramenta? . . . p. 31 5.1.2 O quão difícil é encontrar uma solicitação de revisão de código? p. 32 5.1.3 O quão útil são os dados apresentados em cada solicitação de
revisão? . . . p. 32 5.1.4 O quão eficiente a ferramenta é no sentido de transmitir uma
solicitação de revisão? . . . p. 33 5.1.5 Quais são as vantagens de usar a ferramenta integrada ao GitHub
5.1.6 Quais são as vantagens de usar a ferramenta integrada ao GitHub
ao invés de usar apenas o GitHub no processo de revisão? . . . . p. 33 5.1.7 Como você acha que a ferramenta poderia ser melhorada? . . . p. 34 5.2 Conclusão . . . p. 34
6 Considerações Finais p. 36
6.1 Limitações do estudo . . . p. 36 6.2 Sugestões para trabalhos futuros . . . p. 37
Referências p. 38
12
1
Introdução
Ao longo do desenvolvimento de um projeto de software um conjunto de diferentes práticas compõe um processo que tem por objetivo alcançar um produto de qualidade de maneira eficaz (HUMPHREY, 1995).
A revisão de código é uma destas práticas, sendo uma atividade bastante comum em organizações de desenvolvimento de software, tanto em comunidades open source quanto em softwares privativos (MCINTOSH et al., 2014). Além da sua principal motivação de identificar erros ou oportunidades de melhoria antes do código entrar em produção, a revisão de código promove a transferência de conhecimento e melhoram a awareness entre os desenvolvedores da organização (BACCHELLI; BIRD, 2013).
A prática de revisão de código atualmente costuma ser auxiliada pelo uso de ferramen-tas. Algumas delas fazem revisão automatizada com o uso de análise estática de código, já outras facilitam as revisões de código elaboradas por outros indivíduos. O GitHub1 é uma
das maiores redes de repositório de código. Em 2017, mais de 1.5 milhões de organizações estão presentes na plataforma, produzindo um total de 65 milhões de repositórios de có-digo2. O GitHub também dispõe uma ferramenta de revisão de código, bastante utilizada
pelos seus usuários.
A empresa Alpha, com mais de 100 desenvolvedores de software, faz uso do GitHub. As revisões de código são frequentes e elaboradas através da plataforma. Afim de cultivar o hábito de difundir conhecimento, a empresa incentiva seus desenvolvedores a revisar não só códigos elaborados por membros de sua equipe, mas também revisar códigos de outras equipes. Apesar de sua eficiência, a ferramenta de revisão de código do GitHub carece de uma maneira prática de identificar quais são os códigos que estão precisando de revisão em um determinado momento, e as informações são facilmente perdidas na forma de emails.
1http://github.com
13
É proposta então uma ferramenta que facilite a visualização de solicitações de revisão de código, catalogando e indexando-os em um feed de informações que pode ser consumido de maneira prática pelos desenvolvedores de uma organização de desenvolvimento de soft-ware. Este processo acaba por ampliar o alcance das solicitações de revisão, aprimorando o processo de revisão de código e cultivando a awareness da equipe.
1.1
Objetivos e Perguntas da Pesquisa
Este estudo contempla a concepção e desenvolvimento de uma ferramenta cujo propó-sito é melhorar a visibilidade de códigos que precisam de revisão dentro de uma empresa de desenvolvimento de software.
Para a concepção desta ferramenta, foi elaborado um estudo de caso (seção 3.2) com a empresa Alpha. Neste estudo de caso, o processo de revisão de código da organização foi analisado. Após esta análise, foi possível identificar problemas no processo de revisão da empresa Alpha e obter dados relevantes para a definição de requisitos da ferramenta proposta.
Após a implementação, a ferramenta foi disponibilizada para alguns desenvolvedores da empresa Alpha, e questionários foram aplicados afim de avaliar a ferramenta.
De modo geral, este trabalho busca respostas para as seguintes perguntas:
1. Quais benefícios o uso da ferramenta traz no processo de revisão de código para o desenvolvedor?
2. A ferramenta traz mais visibilidade para códigos que precisam de revisão? 3. Quais funcionalidades poderiam ser adicionadas à ferramenta?
1.2
Casos de uso da ferramenta
Esta seção apresenta os casos de uso da ferramenta: cadastro de uma solicitação de revisão, visualização do feed e fechamento da solicitação de revisão.
14
1.2.1
Cadastro de uma solicitação de revisão
Um determinado desenvolvedor chamado Adriano, após terminar um pull request no repositório de seu projeto, cadastra uma nova solicitação de revisão informando o reposi-tório e o pull request.
O pedido de revisão fica então disponível em um feed de informação disponível para os outros desenvolvedores de sua organização.
1.2.2
Visualização de Feed
Um outro desenvolvedor, Arthur, deseja saber quais são os pull requests que estão disponíveis para serem revisados dentro de sua organização. Arthur então acessa o feed e visualiza todos os pedidos de revisão cadastrados. A partir desta visualização, Arthur escolhe um pull request para revisar.
1.2.3
Fechamento da solicitação de revisão
Após receber revisões em seu pull request, Adriano está satisfeito com o feedback de outros membros de sua organização e pode então fechar o seu pedido de revisão para que ele não fique mais disponível no feed.
1.3
Estrutura do trabalho
Este trabalho é organizado em 6 capítulos. O Capítulo 2 apresenta a revisão de litera-tura relacionada à este trabalho. O Capítulo 3 descreve os passos para o desenvolvimento da ferramenta, trazendo um estudo de ferramentas existentes e um estudo de caso com a empresa Alpha. O Capítulo 4 define a ferramenta desenvolvida, apresentando seus requi-sitos e funcionalidades. O Capítulo 5 apresenta a avaliação da ferramenta na metodologia aplicada, trazendo uma análise e conclusão de seus resultados. O Capítulo 6 traz algumas considerações finais relacionadas a este trabalho, como as limitações do estudo e também apresenta alguma sugestão para trabalhos futuros relacionados com a ferramenta.
15
2
Fundamentação Teórica
Este capítulo contém a fundamentação teórica deste trabalho, apresentando conceitos de revisão de código no processo de desenvolvimento de software; também apresenta do conceito de feeds de informação, principal método de visualização de informação utilizada na ferramenta desenvolvida. Além disso, este capítulo também aborda o tema de awareness em times de desenvolvimento de software.
2.1
Revisão de Código
A revisão de código é uma atividade considerada importante e de baixo custo para a detecção de erros (FAGAN, 2002) no desenvolvimento de um software. A prática tem sido adotada como um mecanismo de garantia da qualidade de código nas maiores e bem sucedidas comunidades open source (RIGBY; STOREY, 2011; ASUNDI; JAYANT, 2007).
Além de detectar defeitos e manter a integridade do código, as revisões de código também trazem outros benefícios como a propagação de conhecimento, expertise e técnicas de de desenvolvimento de software entre os participantes da revisão de código (TURNER et al., 2010;WIEGERS, 2001).
2.1.1
Cinco lições de projetos open source
Em um estudo (RIGBY; STOREY, 2011) realizado com grandes projetos open source bem sucedidos, mais de 100.000 revisões de código foram analisadas. A partir desta análise, cinco importantes características foram notadas:
2.1.1.1 Revisões Assíncronas
Revisões assíncronas dispensam reuniões formais, as revisões são solicitadas e atendi-das sem seguir uma ordem específica. Os próprios revisores escolhem o código que desejam
16
revisar e decidem quando realizar a revisão.
As revisões assíncronas permitem discussões em equipe acerca das possíveis soluções, detectando o mesmo número de defeitos que reuniões formais de revisão de código em menos tempo (VOTTA, 1993). As discussões geradas em torno das soluções permitem um maior aprendizado, envolvendo todos os participantes da revisão em questão, inclusive os passivos, indivíduos ouvintes nas discussões.
2.1.1.2 Revisões Frequentes
Quanto mais cedo um defeito é detectado, melhor. Os desenvolvedores de projetos open source realizam revisões assíncronas de forma frequente e contínua, funcionando muitas vezes como uma espécie de programação em par assíncrono.
2.1.1.3 Revisões Incrementais
As revisões de código devem ser em cima de mudanças pequenas, independentes e completas. Projetos open source tendem a revisar pequenas mudanças de código por vez (MOCKUS; FIELDING; HERBSLEB, 2002), isto permite o revisor focar na mudança por inteira, reduzindo o tempo de preparação para a revisão.
2.1.1.4 Revisores especialistas
Especialistas e coautores realizar as revisões do código pelo fato de já possuírem o domínio de entendimento do contexto na qual a mudança está sendo feita.
2.1.1.5 Empoderamento dos revisores
Processos rígidos e mal implementados podem levar à ilusão de estar seguindo boas práticas, enquanto que nem um benefício sequer está sendo obtido (PORTER et al., 1988), pode ser difícil identificar quem deve revisar ou quantos revisores serão necessários.
Por outro lado, deixar que os próprios revisores escolham as mudanças que desejam revisar acaba por ser um processo natural e equilibrado para a equipe de desenvolvimento. Permitindo que os revisores selecionem mudanças de código em que possuem algum domí-nio. No entanto, esta auto-seleção dos revisores pode levar a algumas mudanças de código ignoradas. Neste caso, gerentes podem recorrer ao uso de ferramentas automatizadas para atribuir revisores nestas situações.
17
2.2
Feed de informação
Feed de informação é uma forma de visualização de informação definida por uma sequência de eventos que seguem uma determinada ordenação. Geralmente é composto por um ou mais canais de informação, onde o consumidor da informação se inscreve para poder consumir as informações, item por item (TSENG; CHEN; CHEN, 2012).
Geralmente o feed possui uma ordenação cronológica, apresentando os eventos se-guindo uma sequência temporal. Desta forma, o consumidor da informação tem uma visão ampla dos eventos e é uma forma de visualizar e consumir informações bastante presente em redes sociais, como Twitter e Facebook (DALY et al., 2010). Permite o consumidor da informação ter uma visão ampla em curta escala dos eventos de um determinado canal em que ele está inscrito.
Devido a natureza contínua do desenvolvimento de um software, um feed pode ser uma eficiente maneira de visualizar as inúmeras informações geradas no decorrer do processo de desenvolvimento.
2.3
Awareness
O desenvolvimento de software é um trabalho colaborativo (HERBSLEB et al., 2001). Em uma atividade colaborativa é importante que os indivíduos estejam cientes dos traba-lhos uns dos outros. O termo awareness pode ser compreendido como este entendimento do trabalho dos outros indivíduos em um grupo, é o conhecimento compartilhado à respeito de quem está envolvido e no que cada indivíduo está trabalhando (DOURISH; BELLOTTI, 1992).
Cultivar awareness em um grupo traz um impacto positivo nas relações entre seus integrantes, pois torna mais fácil a ocorrência de integrações informais e conexões espon-tâneas (SHAH; MARCHIONINI, 2010).
18
3
Metodologia
O objetivo deste trabalho é a concepção e desenvolvimento de uma ferramenta capaz de emitir solicitações de revisão de código e reuni-las em único canal de informações que pode ser acessado pelos membros de uma organização de desenvolvimento de software. Este capítulo traz um estudo de ferramentas semelhantes existentes e também um estudo de caso do processo de revisão de código de três projetos de uma empresa de desenvolvi-mento de software.
3.1
Estudo de ferramentas existentes
3.1.1
GitHub
O GitHub foi criado em 2002 com a ideia de criar uma comunidade de desenvolvimento e manutenção de projetos open source que utilizam o sistema de controle de versionamento Git. Atualmente é a maior plataforma online de repositórios de código do mundo. Com suporte à repositórios de código fechado e muitas outras ferramentas de desenvolvimento. É a escolha de muitas organizações, tanto privativas quanto open source.
A plataforma também disponibiliza aos seus usuários uma ferramenta de revisão de código. Através dela, é possível solicitar revisões de código.
19
Figura 1: Ferramenta de revisão de código do GitHub
Porém, esta solicitação é transmitida de maneira direta: quem deseja solicitar uma revisão de código precisa indicar quem que o desenvolvedor deseja como revisor de seu código.
Figura 2: Exemplo de solicitação de revisão de código no GitHub
Um problema possível neste processo de solicitação de revisão de código é que nem sempre o autor do código saberá quais ou quantos desenvolvedores ele deve indicar para realizar a revisão.
Quando um desenvolvedor é solicitado para uma revisão de código, uma notificação é enviada através de email ao desenvolvedor. Esta notificação muitas vezes não é eficaz,
20
pois a informação é facilmente perdida em meio à outras tantas notificações de email não relacionadas à solicitação enviadas pelo próprio GitHub.
3.1.2
Gerrit
Gerrit é um software livre de revisão de código para projetos que fazem uso do sistema de controle de versão Git. Através da ferramenta, seus usuários podem submeter mudanças de código para revisões e revisar mudanças de código de autoria de outros desenvolvedores.
Figura 3: Ferramenta de revisão de código do Gerrit
Toda solicitação de revisão fica disponível em uma tabela para inspeções de outros desenvolvedores que possuem acesso ao canal. Através da ferramenta é possível cadastrar comentários por linha de código e gerar discussões em grupo acerca da solução proposta.
21
A ferramenta é eficiente no processo de revisão de código. O próprio time de desen-volvimento do Gerrit faz uso da plataforma para realizar revisões de código do projeto1.
Para fazer uso da ferramenta, ela deve ser instalada e configurada manualmente em um servidor próprio da organização.
3.1.3
Stack Exchange: Code Review
O Stack Exchange é a maior rede de perguntas e respostas da área de TI. Ele é composto por diversos subdomínios, cada um correspondendo a um determinado domínio de conteúdo. Em abril de 2014, o seu site principal, o StackOverflow, obteve mais de 4 milhões de usuários e mais de 11 milhões de perguntas 2. O Stack Exchange também
possui um subdomínio voltado para revisões de código 3.
Figura 5: Exemplo de solicitação de revisão no Stack Exchange
O Stack Exchange Code Review permite que os desenvolvedores solicitem revisões de código. As solicitações ficam listadas em um feed público, onde qualquer pessoa pode acessar. Por utilizar o mesmo padrão de perguntas e respostas da rede Stack Exchange, a ferramenta não é eficiente para a revisão grandes mudanças de código. Não é possível inserir comentários por linha de código, e o código a ser revisado é inserido e formatado pelo próprio autor.
1https://gerrit-review.googlesource.com
2https://stackoverflow.blog/2015/01/08/year-in-review-2014/ 3https://codereview.stackexchange.com/
22
Figura 6: Exemplo de revisão no StackExchange Code Review
Conforme o exemplo ilustrado na imagem acima, as revisões no StackExchange tendem a ser profundas e bem detalhadas, o que pode ser muito bom para o aprendizado, porém impraticável dentro de um processo de revisão de código, onde existe a expectativa de feedbacks rápidos e pontuais, com revisões e solicitações de revisões frequentes.
3.2
Estudo de caso
Após realizar um estudo das ferramentas existentes, um estudo de caso com a em-presa Alpha foi feito. Ao longo de uma semana, três equipes de desenvolvimento foram acompanhados, afim de de identificar as etapas, o funcionamento e possíveis problemas do processo de revisão de código em seus projetos.
3.2.1
Contexto da Empresa Alpha
A empresa Alpha é uma empresa americana de desenvolvimento de software que presta serviços de desenvolvimento e consultoria para diversos clientes nos Estados Unidos. Seu time conta com 120 desenvolvedores distribuídos nos mais variados países, todos traba-lhando remotamente pela empresa. A grande parte dos projetos da empresa são aplicações web, uma outra parte são projetos de aplicativos móveis.
Para a elaboração deste trabalho, houve a participação de 8 desenvolvedores da em-presa Alpha. Destes 8 desenvolvedores, três trabalham no projeto Azul, dois no projeto Verde e o restante no projeto Amarelo. Todos os desenvolvedores possuíam acesso aos três projetos.
23
Os desenvolvedores foram acompanhados durante uma semana afim de identificar como eles solicitam revisões de código em cada projeto. Foi observado que as revisões de código eram solicitadas e realizadas através do GitHub.
De uma maneira geral, as etapas do processo de revisão de código para os três times podem ser definidas da seguinte maneira:
1. Bill termina um pull request ; 2. Bill solicita uma revisão a Ted;
3. Ted recebe uma notificação por email sobre a solicitação de revisão; 4. Ted acessa um link para realizar a revisão do código através do email; 5. Ted revisa o código do Bill.
Foi notado que a notificação da etapa 3 nem sempre é eficiente, pois a notificação é perdida facilmente em meio a outros tipos de notificações na caixa de entrada do desen-volvedor. Devido a este problema, os desenvolvedores recorrem muitas vezes a solicitar a revisão diretamente a um outro desenvolvedor através de uma aplicação de troca de mensagens de texto:
Figura 7: Desenvolvedor solicitando diretamente uma revisão de código à um outro de-senvolvedor através da aplicação de mensagens de texto
Quando os desenvolvedores não fazem esta solicitação diretamente ao revisor, é comum a revisão ficar pendente até instantes antes do código entrar em produção. Isto pode gerar atrasos na entrega de novas funcionalidades ou correções, pois caso haja mudanças de código solicitadas pelo revisor, o código não poderá entrar em produção naquele momento. Também foi observado que, apesar da revisão de código ser uma prática comum dentro dos times, os desenvolvedores só revisavam códigos escritos por desenvolvedores do seu time, mesmo quando os projetos compartilham tecnologias, como a mesma linguagem de programação ou framework.
24
3.2.2
Coleta e análise de dados
A ferramenta foi hospedada em um servidor e disponibilizada para quem possuía acesso ao endereço. O endereço foi então compartilhado com os mesmos oito participantes do estudo de caso. Os participantes fizeram uso da ferramenta em seus projetos durante uma semana de trabalho.
Após a semana de uso, um questionário contendo seis perguntas foi enviado aos par-ticipantes. Através dos dados coletados pelo questionário, o autor produziu uma análise. O questionário de avaliação da ferramenta encontra-se no Apêndice A deste docu-mento.
25
4
Definição e implementação de
requisitos
Este capítulo apresenta os requisitos funcionais e não-funcionais da ferramenta, suas funcionalidades, e alguns detalhes acerca de sua implementação.
4.1
Definição de Requisitos
Com base na análise do estudo de caso realizado com os desenvolvedores da empresa Alpha, o autor levantou os seguintes requisitos para o desenvolvimento da ferramenta:
1. As solicitações de revisão de código devem ser feitas sob pull requests do GitHub.
A ferramenta deverá ser integrada ao GitHub, afim de relacionar cada solicitação de revisão à um pull request.
2. O solicitador da revisão deve ser identificado.
A identificação do solicitador da revisão é importante para se ter conhecimento de sua origem.
3. A solicitação deve exibir a data e a hora de sua criação.
A exibição da data e da hora da criação da solicitação é uma importante orientação da ordem do feed.
4. A solicitação deve exibir breves informações à respeito do pull request. Alguns dados a respeito do pull request devem ser apresentados, como o título e o autor. Outros dados são relevantes para o revisor ter uma noção do tamanho do pull request, como número de linhas adicionadas e removidas, ou número de arquivos modificados.
26
5. A ordem do feed de solicitações deve ser cronológica e decrescente. A listagem das solicitações no feed será ordenada da mais nova para a mais velha em data de criação.
6. Deve ser possível fechar uma solicitação de revisão.
Fechar uma solicitação é uma forma de retirar a solicitação do feed, afim de expressar que aquela solicitação não é mais necessária.
7. Cada solicitação deve ter um link para a revisão do pull request no GitHub.
Um link para revisar o pull request na ferramenta de revisão do GitHub é uma forma de integrar
4.1.1
Funcionalidades
Com os requisitos definidos, as seguintes funcionalidades foram implementadas:
4.1.1.1 Autenticar-se usando conta do GitHub
A autenticação com o GitHub é uma funcionalidade importante, pois é através desta autenticação que a ferramenta terá permissões de leitura de dados relacionados aos usuá-rios, repositórios e pull requests.
Figura 8: Tela de login
Esta autenticação é uma etapa obrigatória, e é o primeiro passo para iniciar a ferra-menta.
27
4.1.1.2 Cadastrar solicitação de revisão a partir de pull request
Autenticado, o usuário pode cadastrar uma solicitação de revisão de código. O cadas-tro desta solicitação pode ser definida em três etapas:
1. Seleção de repositório 2. Seleção de pull request 3. Cadastro de solicitação
Ao cadastrar uma solicitação de revisão, é necessário primeiro selecionar o repositório do GitHub em que o pull request pertence. Esta é uma etapa obrigatório que permite a ferramenta consultar e listar os pull requests do repositório.
Após selecionar o repositório, uma lista de pull requests será carregada e exibida para o usuário. A partir daí o usuário seleciona o pull request que ele deseja que seja revisado a partir da sua solicitação.
Com o repositório e o pull request selecionados, o usuário pode criar a solicitação. A solicitação da revisão é então adicionada ao feed.
Figura 9: Cadastro de solicitação de revisão de código
4.1.1.3 Visualizar solicitação de revisão
Após o seu cadastro, a solicitação de revisão é adicionada ao feed, tornando a sua exibição disponível para os outros usuários da ferramenta.
28
Figura 10: Visualização da solicitação de revisão
Cada solicitação de revisão de código exibe um conjunto de dados relacionados ao pull request no GitHub:
• Título do pull request no GitHub
• Número atual de revisões realizadas através do GitHub
• Número de commits que o pull request possui em comparação ao branch principal.
• Número de linhas adicionadas • Número de linhas removidas
• Linguagens de programação utilizadas no repositório • Nome do usuário do solicitador
• Nome do repositório
4.1.1.4 Abrir ferramenta de revisão de código do GitHub
Cada solicitação dispõe de um link que leva o revisor diretamente à revisão do código utilizando a ferramenta de revisão de código do GitHub.
29
Figura 11: Ferramenta de revisão de código do GitHub
4.1.1.5 Encerramento de solicitação de revisão
A qualquer momento o solicitador pode efetuar o encerramento de sua solicitação após a sua criação. Uma solicitação encerrada não é exibida mais no feed de solicitações. Normalmente o solicitador vai encerrar sua solicitação quando estiver satisfeito com as revisões que o seu pull request recebeu.
Para realizar esta ação, o usuário precisa confirmar sua intenção em uma janela:
30
4.1.1.6 Fechar sessão
Os dados da sessão do usuário se encontram no canto superior direito da ferramenta. O usuário pode encerrar a sua sessão ao clicar em Logout.
Figura 13: Sessão do usuário
4.1.2
Implementação
O código fonte desta ferramenta é open source, sob a licença MIT, e está hospedado no GitHub. Todo o código fonte da ferramenta pode ser acessada através do endereço:
https://github.com/brnrdog/please-review
Uma instância da ferramenta também pode ser acessada através da seguinte url:
31
5
Análise e discussão dos resultados
Para a avaliação da ferramenta proposta, um questionário contendo seis perguntas foi disponibilizado para os participantes deste estudo. Este capítulo apresenta as respostas do questionário, bem como uma análise sobre os resultados obtidos.
5.1
Respostas do questionário
5.1.1
O quão difícil é o uso da ferramenta?
Figura 14: Primeira pergunta. Respostas em escala: 1 - difícil; 5 - fácil.
Todos os participantes responderam que a ferramenta é de uso fácil, indicando que as funcionalidades presentes na ferramenta são diretas e intuitivas.
32
5.1.2
O quão difícil é encontrar uma solicitação de revisão de
código?
Figura 15: Segunda pergunta. Respostas em escala: 1 - difícil; 5 - fácil.
Os oito participantes responderam que é fácil encontrar uma solicitação de revisão de código através do uso da ferramenta.
5.1.3
O quão útil são os dados apresentados em cada solicitação
de revisão?
Figura 16: Terceira pergunta. Respostas em escala: 1 - Não útil; 5 - Útil.
Foi observado que os dados exibidos em cada solicitação de revisão de código são relativamente úteis.
Alguns participantes destacaram a utilidade de exibir dados relativos ao tamanho da mudança de código a ser revisado, pois ajuda na seleção do pull request a ser revisado, uma vez que o tamanho está relacionado com o tempo a ser investido na revisão.
33
5.1.4
O quão eficiente a ferramenta é no sentido de transmitir
uma solicitação de revisão?
Figura 17: Quarta pergunta. Respostas em escala: 1 - Ineficiente; 5 - Eficiente.
Segundo os participantes, a ferramenta é eficiente na transmissão de solicitações de revisões de código. As solicitações ficam disponibilizadas em um único canal, acessível por todos os integrantes do experimento. Não há necessidade de atribuir revisores.
Um dos participantes ressaltou que a necessidade de algum sistema de notificação para alertar os integrantes quando novas solicitações surgem.
5.1.5
Quais são as vantagens de usar a ferramenta integrada ao
GitHub ao invés de usar apenas o GitHub no processo de
revisão?
A partir das repostas dos participantes, notou-se que a maior vantagem da ferramenta sob o GitHub é a existência de um canal dedicado à solicitações de revisão de código. Segundo os participantes a ferramenta torna o processo de revisão de código mais ágil ao disponibilizar as solicitações de código para todos os participantes de um único canal.
5.1.6
Quais são as vantagens de usar a ferramenta integrada ao
GitHub ao invés de usar apenas o GitHub no processo de
revisão?
A partir das repostas dos participantes, notou-se que a maior vantagem da ferramenta sob o GitHub é a existência de um canal dedicado à solicitações de revisão de código.
34
Segundo os participantes a ferramenta torna o processo de revisão de código mais ágil ao disponibilizar as solicitações de código para todos os participantes de um único canal.
5.1.7
Como você acha que a ferramenta poderia ser melhorada?
Seis participantes sugeriram melhorias para a ferramenta. As melhorias sugeridas à seguir correspondem à novas funcionalidades que poderiam ser agregadas à ferramenta:
1. Notificações em tempo real de novas solicitações de revisão; 2. Notificações por e-mail de novas solicitações de revisão;
3. Opções de filtro no feed de solicitações, afim de melhorar o processo de seleção de pull request por parte do revisor;
4. Integração com outros serviços além do GitHub, como GitLab e BitBucket;
5. Personalização de feed , priorizando as solicitações no topo do feed de acordo com a especialização do desenvolvedor.
5.2
Conclusão
A partir das respostas obtidas através do questionário, podemos obter as respostas para as perguntas iniciais descritas na seção 1.1 deste documento.
1. Quais benefícios o uso da ferramenta traz no processo de revisão de código para o desenvolvedor?
Segundo os participantes da pesquisa, os benefícios que a ferramenta traz para o processo de revisão de código são:
(a) Disponibiliza todas as solicitações centralizando em um único canal de infor-mação;
(b) Facilita as solicitações de revisão de código;
(c) Facilita as visualizações e a seleção de códigos para revisor; (d) Retira a necessidade de atribuir revisores;
35
(f) As solicitações de revisão de código são atendidas com maior velocidade;
2. A ferramenta traz mais visibilidade para códigos que precisam de revisão? A ferramenta traz um único canal de informações, disponibilizando todas as so-licitações de revisão de código para todos os indivíduos inscritos no canal. Esta centralização de informação tem como resultado uma maior visibilidade para as solicitações de revisão, resultando em revisões mais frequentes.
3. Quais funcionalidades poderiam ser adicionadas à ferramenta?
(a) Notificações de novas solicitações de revisão de código em tempo real; (b) Notificações de novas solicitações de revisão de código via email;
(c) Opções de filtro no feed de solicitações, como linguagens de programação, re-positórios;
(d) Integração com outras plataformas de repositório de código, como GitLab e BitBucket;
36
6
Considerações Finais
A ferramenta apresentada neste trabalho visa a melhoria do processo de revisão de código dentro de uma organização de desenvolvimento de software. A introdução de um canal único para revisões de código pode trazer benefícios para uma organização de desen-volvimento de software. A experiência com os desenvolvedores participantes deste estudo mostrou que a ferramenta traz suporte ao modelo de revisões assíncronas, incentiva o hábito de revisões frequentes e melhora a experiência de seleção de código para revisar por parte do revisor. Apesar disso, os resultados obtidos pertencem a um contexto bem definido da empresa Alpha, e a experiência de uso da ferramenta em outros grupos de contextos diferentes pode ser diferente.
Este capítulo descreve algumas limitações deste estudo e apresenta algumas sugestões de trabalhos futuros relacionados à ferramenta.
6.1
Limitações do estudo
1. A ferramenta foi avaliada dentro do um único contexto, com apenas 8 desenvolve-dores em 3 projetos distintos.
2. O período de uso da ferramenta foi de uma semana, o que pode ser considerado curto para avaliar seu impacto no processo de desenvolvimento das equipes envolvidas. 3. Apesar da participação de oito desenvolvedores da empresa Alpha, apenas seis
37
6.2
Sugestões para trabalhos futuros
1. Avaliação da ferramenta no contexto open source.
Organizações open source possuem uma forte cultura de revisão de código e uma dinâmica bem diferente de organizações privadas. A avaliação da ferramenta com organizações open source pode gerar resultados interessantes.
2. Introdução e validação de novos requisitos.
A avaliação da ferramenta apresentada neste trabalho revelou algumas funcionali-dades que poderiam ser agregadas à ferramenta. A introdução e validação de novos requisitos pode ser um estudo interessante com a ferramenta.
3. Integração com outros serviços de repositório de código.
A ferramenta suporta apenas integração com o GitHub. Existem diversos outros serviços no mercado que poderiam possuir integrações com a ferramenta. Para citar alguns: BitBucket, GitLab, Google Cloud Source, AWS CodeCommit.
38
Referências
ASUNDI, J.; JAYANT, R. Patch review processes in open source software development communities: A comparative case study. 2007.
BACCHELLI, A.; BIRD, C. Expectations, outcomes, and challenges of modern code review. 2013. Disponível em: <"https://dl.acm.org/citation.cfm?id=2486882">. DALY, E. M. et al. Social networking feeds:
re-commending items of interest. 2010. Disponível em:
<https://pdfs.semanticscholar.org/271b/eeb2c3129e0fa6a7989a73f68d96c82f29a9.pdf>. Awareness and coordination in shared workspaces. Disponível em:
<http://www.dourish.com/publications/1992/cscw92-awareness.pdf>. FAGAN, M. Reviews and inspections. 2002.
HERBSLEB, J. D. et al. An empirical study of global software development: distance and speed. 2001.
HUMPHREY, W. A discipline for software engineering. Addison-Wesley, 1995. Disponível em: <"https://dl.acm.org/citation.cfm?id=526906">.
MCINTOSH, S. et al. The impact of code review coverage and code review participation on software quality: a case study of the qt, vtk, and itk projects. 2014. Disponível em: <"https://dl.acm.org/citation.cfm?id=2597076">.
MOCKUS, A.; FIELDING, R.; HERBSLEB, J. Trans. software eng. and methodology. ACM Transactions on Software Engineering and Methodology (TOSEM), 2002.
PORTER, A. et al. Understanding the sources of variation in software inspections. 1988. RIGBY, P. C.; STOREY, M.-A. Understanding broadcast based peer review on open source software projects. 2011.
SHAH, C.; MARCHIONINI, G. Awareness in collaborative information seeking. Journal of the American Society for Information Science and Technology, 2010.
TSENG, C.-Y.; CHEN, Y.-J.; CHEN, M.-S. Socfeedviewer: A novel visualization technique for social news feeds summarization on social network services. 2012. TURNER, S. et al. Peer review in cs2: conceptual learning. 2010.
VOTTA, L. Does every inspection need a meeting? 1993.
WIEGERS, K. E. Peer Reviews in Software: A Practical Guide. [S.l.]: Addison-Wesley, 2001.
39
APÊNDICE A -- Questionário
Para as perguntas de número 1 ao número 4, as respostas foram dadas em escala:
•Perguntas 1 e 2: escala de dificuldade, 1 difícil, 5 fácil. •Pergunta 3: escala de utilidade, 1 pouco útil, 5 muito útil.
•Pergunta 4: escala de eficiência, 1 pouco eficiente, 5 muito eficiente.
1.O quão difícil é o uso da ferramenta?
40
3.O quão útil são os dados apresentados em cada solicitação de revisão?
42
5.Quais são as vantagens de usar a ferramenta integrada ao GitHub ao invés de usar apenas o GitHub no processo de revisão?
