Pull Requests Considerados Prejudiciais
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Pull Requests Considerados Prejudiciais
Em qualquer time de software que você olhe hoje em dia, feature branching e pull requests (PRs) são dados como certos. O estilo de desenvolvimento git-flow tomou a indústria de assalto. É ensinado na maioria dos lugares e considerado a maneira de entregar software.
Isso é um desenvolvimento recente, e nem sempre foi assim. Não é a única forma de programar e pode criar um impacto negativo.
Primeiro, o desenvolvimento baseado em git-flow / feature branching / PRs foi concebido para Software de Código Aberto (OSS). Esses são muito diferentes do seu típico time colaborativo de produto, trabalhando em fusos horários similares. Brian faz esse ponto de forma muito mais clara:
O desenvolvimento de software OSS faz sentido como um processo assíncrono e abrangente. O código é submetido e revisado de forma intermitente. As pessoas podem razoavelmente trabalhar em cópias um pouco diferentes. A integração pode ser adiada com segurança.
No entanto, a maioria dos times remunerados é o oposto: a composição é bem definida, os membros são avaliados e (esperamos) mentorados, e todo mundo é pago para aparecer.
E esse não é um tema novo. Muitos antes de mim já falaram sobre isso. Existe até um site dedicado ao assunto em trunkbaseddevelopment.com.
Por que estou discutindo isso agora?
É um interesse pessoal. Eu nunca tinha criado um PR até 6 meses atrás. Minha carreira de quase 13 anos em tecnologia começou na ThoughtWorks, onde o Trunk Based Development era continuamente promovido. Depois, trabalhei em um time de engenharia na minha própria empresa e raramente criava branches.
Sempre trabalhei em times de 5 a 40 engenheiros que faziam commit direto na master. Isso nunca foi um problema.
Ao entrar em uma empresa de tecnologia maior, me deparei com uma pilha constante de PRs esperando revisão. Engenheiros trabalhando em múltiplos itens simultaneamente enviam PRs, ficam bloqueados e seguem em frente. Esse fluxo de trabalho gera estresse.
O que há de errado com feature branches e PRs?
Esse modelo de trabalho foi projetado para OSS, não para o time comercial comum. PRs atrasam os times e podem criar padrões que reduzem a colaboração e aumentam os riscos técnicos.
Não é preto no branco. PRs podem ter benefícios. Mas devemos considerar o preço que estamos pagando por eles e torná-los mais eficazes.
Vou abordar problemas específicos em uma série de mini posts, começando com A Lentidão dos Pull Requests.