Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra

Departamento de Informática e Matemática AplicadaBacharelado em Engenharia de Software

Please Review: Um feed de solicitações derevisã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 decódigo integrado ao GitHub

Monografia de Graduação apresentada aoDepartamento de Informática e MatemáticaAplicada do Centro de Ciências Exatas e daTerra da Universidade Federal do Rio Grandedo Norte como requisito parcial para a ob-tenção do grau de bacharel em Engenhariade Software.

Orientador

Prof. Dr. Fernando Marques Figueira Filho

Universidade Federal do Rio Grande do Norte – UFRNDepartamento 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.

RN/UF/BSE-CCET CDU: 004.41

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 FilhoOrientador

Departamento de Informática e Matemática AplicadaUFRN

Profa. Dra. Márcia Jacyntha Nunes Rodrigues LucenaDepartamento de Informática e Matemática Aplicada

UFRN

Prof. Dr. Gibeon Soares De Aquino JuniorDepartamento de Informática e Matemática Aplicada

UFRN

Natal-RN, 27 de Novembro de 2017

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

Obrigado à todos os que acreditaram em mim.

Please Review: Um feed de solicitações de revisão decó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.

Palavras-chave: Revisão de código. Feed. Desenvolvimento de Software. Awareness.

Please Review: A review request feed integrated withGitHub

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.

Keywords : Code Review. Feed. Software Development. Awareness.

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

ao invés de usar apenas o GitHub no processo de revisão? . . . . p. 33

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

Apêndice A -- Questionário p. 39

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.com2https://octoverse.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.

Figura 4: Lista de mudanças de código no Gerrit

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.com2https://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 derequisitos

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:

Figura 12: Confirmação de encerramento da solicitação de revisão

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:

http://please-review.herokuapp.com

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 decó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çãode 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 transmitiruma 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 aoGitHub ao invés de usar apenas o GitHub no processo derevisã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 aoGitHub ao invés de usar apenas o GitHub no processo derevisã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;

(e) Estimula a prática de revisões assíncronas;

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;

(e) Personalização de feed baseada nas características do usuário em sessão;

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 fize-

ram uso frequente da ferramenta.

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 developmentcommunities: A comparative case study. 2007.

BACCHELLI, A.; BIRD, C. Expectations, outcomes, and challenges of modern codereview. 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: distanceand 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 participationon 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 opensource software projects. 2011.

SHAH, C.; MARCHIONINI, G. Awareness in collaborative information seeking. Journalof the American Society for Information Science and Technology, 2010.

TSENG, C.-Y.; CHEN, Y.-J.; CHEN, M.-S. Socfeedviewer: A novel visualizationtechnique 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?

2.O quão difícil é encontrar uma solicitação de revisão de código?

40

3.O quão útil são os dados apresentados em cada solicitação de revisão?

4.O quão eficiente a ferramenta é no sentido de transmitir uma solicitação de revisão?

41

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?

6.Como você acha que a ferramenta poderia ser melhorada?