O que as solicitações pull do GitHub revelam sobre os hábitos de desenvolvimento da sua equipe

Oprimido por problemas duplicados registrados em seu projeto GitHub? Ou por pull requests concorrentes que estão consumindo o tempo da sua equipe? Seu estilo de comunicação, ou forma de delegar trabalho, pode ser parte do problema, descobriram os pesquisadores.

Como qualquer gerente de projeto sabe, os desenvolvedores trabalham com base em problemas e solicitações pull (PR) no git e em serviços git, como GitHub e GitLab.

Um grupo de pesquisadores da Universidade Federal do Pará, Brasil, e da Universidade da Colúmbia Britânica estudou esses comportamentos de codificação, mapeando-os em um gráfico para ver quais “padrões ocultos” poderiam ser encontrados.

A busca por esses padrões no desenvolvimento de sua própria equipe pode revelar áreas onde o fluxo de trabalho pode ser otimizado.

“Se o seu projeto tiver uma quantidade desproporcional de PRs concorrentes, ou ‘centros de problemas duplicados’, ele pode ser designado para revisar sua revisão de código ou práticas de relatório de bugs”, observou Emilie Ma, uma das pesquisadoras que falou na Linux Foundation Open Source Cimeira no início deste ano.

Como os pesquisadores rastreiam o comportamento do GitHub?

A equipe analisou 56 projetos GitHub, capturando todos os problemas e PRs gerados por esses projetos. Em um modelo de gráfico (capturado no Neo4j), os problemas e os PRs foram representados como nós, e os links entre eles foram representados como arestas.

Em um fluxo de trabalho git, os problemas são criados para identificar o trabalho a ser realizado. O código resultante criado é então agrupado em PRs que normalmente são revisados ​​antes de serem mesclados no corpo central do código. Num mundo ideal, um único PR resolve o problema.

Em termos de ligações, as questões poderiam estar abertas (o que significa que o trabalho ou a discussão estava em curso) ou poderiam ser fechadas. O mesmo acontece com os PRs, exceto que, uma vez finalizados, eles atingem outro status, sendo mesclados. Tanto os problemas quanto os PRs podem ser duplicados. Autores e carimbos de data/hora também foram coletados.

“Esta abordagem baseada em gráficos fornece uma janela para um conjunto de práticas colaborativas de engenharia de software que não foram descritas anteriormente”, escreveram os pesquisadores.

No processo, eles construíram uma ferramenta de visualização, WorkflowsExplorer, para exibir os resultados.

Estudos anteriores analisaram problemas e solicitações pull de forma independente, embora seja útil estudá-los em conjunto. “Questões e PRs estão acoplados na prática:
Os problemas são frequentemente resolvidos com PRs, e os PRs estão associados a Problemas”, escreveram os pesquisadores.

A metodologia dos pesquisadores (“Revealing Software Development Work Patterns with
Topologias de gráfico de emissão de PR”)

Padrões básicos de fluxo de trabalho do GitHub

Como resultado desses trabalhos, os pesquisadores encontraram oito tipos distintos de fluxo de trabalho, ou padrões de comportamento, que compunham mais de 1.000 instâncias de ações de desenvolvimento.

“Cada uma dessas definições de tipo de fluxo de trabalho está associada a uma prática de trabalho”, disse Ma.

Gráficos dos diferentes tipos de padrões de fluxo de trabalho, ou comportamentos, encontrados pela equipe de pesquisa (“Revealing Software Development Work Patterns with
Topologias de gráfico PR-Issue”).

Não surpreendentemente, 35,7% dos tipos de relacionamento eram de simples resolução de um problema. Mas havia muitos outros padrões, alguns bons e outros nem tanto.

Aqui está um tipo de fluxo de trabalho que eles encontraram, “PRs concorrentes”: dois ou mais codificadores propõem um recurso separadamente e cada um envia um PR.

No caso de PRs concorrentes, “os colaboradores tendem a estar ansiosos demais para contribuir com suas próprias implementações de uma tarefa sem comunicar de outra forma”, disse Ma.

O facto de apenas um dos PR ter sido aceite sugere que o projecto tem comunicações abaixo do ideal, uma vez que há trabalho duplicado em curso. Um PR pode ser rejeitado porque prejudica muito o desempenho, mas outro é aceito.

No entanto, o lado positivo é que esse comportamento permite que o projeto “seja mais exigente” na aceitação de PRs, disse Ma.

Outro padrão: problemas duplicados. Aqui são levantadas múltiplas questões, independentes umas das outras. Se você tiver alguns problemas duplicados, terá um “centro de problemas duplicados”, explicou Ma. Este é outro potencial negativo para o projeto.

Mudanças significativas são uma causa frequente de hubs de problemas duplicados. São um sinal de que o projeto pode ser mais articulado nas suas mensagens sobre as mudanças futuras.

“Centros de problemas duplicados tendem a surgir por colaboradores que não estão cientes do trabalho que está sendo realizado em um projeto ou que simplesmente não se preocuparam em pesquisar problemas anteriores. E isso causa uma carga adicional de manutenção”, disse Ma.

“Pode ser atribuído para reavaliar como você está enviando mensagens, a mudança que está causando esses problemas duplicados para melhor informar os usuários”, disse Ma.

No entanto, problemas gerais de duplicação surgem com menos frequência do que você imagina. Os pesquisadores identificaram apenas 15 instâncias de nós de emissão duplicados nos 90.000 nós estudados.

Ela apontou para um projeto Apache que criou um bot semanal para montar uma edição de todos os PRs que foram mesclados naquela semana, informando a todos quais atualizações foram feitas.

Um desenvolvedor excessivamente ansioso pode levar a outro padrão problemático, o de resolver vários problemas em um único PR (PR Divergente). Isso pode atrasar a equipe porque esses PRs com cabeça de hidra exigirão mais tempo para revisão, já que o revisor pode não estar familiarizado com todas as questões que estão sendo abordadas.

Nem todos os padrões são problemáticos.

Para adicionar grandes recursos, uma loja pode usar PR Decomposto, que envolve não um, mas vários PRs encadeados. Cada um faz parte de um trabalho (“frontend”) e pode contar com outros PRs (“backend”) para completar o problema. Freqüentemente, eles são preenchidos por um único autor, que pode enviar um PR e depois iniciar outro enquanto o primeiro está sendo revisado.

Essa abordagem é frequentemente considerada um padrão positivo, pois torna o código mais fácil de escrever, revisar e confirmar, especialmente para projetos maiores.

O que os tipos de fluxo de trabalho dizem sobre o seu projeto

No geral, foram encontrados tipos de fluxo de trabalho em todos os projetos estudados, embora projetos maiores tivessem mais desses padrões. O maior desses projetos tinha mais de 150 tipos de fluxo de trabalho.

“Existe uma ligação entre a maturidade de um projeto e a sua necessidade de colaboração estruturada e altamente organizada que se manifesta nestes tipos de fluxo de trabalho”, disse Ma.

Para validar suas descobertas, a equipe de pesquisa entrevistou vários desenvolvedores de projetos, que viram valor nesta abordagem para ajudar a melhorar a revisão de código e as práticas de gerenciamento de projetos. PRs divergentes, por exemplo, poderiam ser um sinal para mais priorização de revisão de código.

“Pense neste gráfico de PR/Issue como uma espécie de Grafana para monitorar a saúde da colaboração do seu projeto, (um) que pode ajudar a identificar áreas problemáticas e servir como um ponto de referência global para entender o seu projeto como um todo”, disse Ma.

O artigo detalhando todo o trabalho, “Revealing Software Development Work Patterns with PR-Issue Graph Topologies”, será apresentado no dia 18 de julho na Conferência Internacional ACM sobre os Fundamentos da Engenharia de Software que acontece no Brasil. Cleidson de Souza, Jesse Wong, Dongwook Yoon e Ivan Beschastnikh foram os outros autores deste trabalho.

A postagem O que as solicitações pull do GitHub revelam sobre os hábitos de desenvolvimento da sua equipe apareceu pela primeira vez em The New Stack.