Os pedidos pull são o local para treinar juniores

11

Temos um conceito de que todo código em uma solicitação de recebimento no mestre deve estar pronto para produção. Isso faz sentido e é uma afirmação justa na minha opinião.

A ideia aqui é que, depois de criar o PR, você esteja declarando que você o colocaria no mestre, mas gostaria que alguns revisores simplesmente 'concordassem' com você e localizassem qualquer coisa que você perdesse.

Como somos humanos, cometemos erros e esperamos que outros revisores possam encontrar itens que os testes de unidade não puderam encontrar - erros de ortografia, javadocs incorretos etc.

MAS, é uma solicitação de recebimento o local em que devemos fornecer algum nível de assistência / treinamento aos desenvolvedores e, em caso afirmativo, em que nível?

Cada vez que você pressiona novas alterações, os revisores precisam revisar suas alterações, o que leva a partir do tempo de desenvolvimento e causa a revisão de alterações.

Portanto, quanto treinamento é esperado, deve ser permitido, em solicitações pull? Parte de mim sente que varia de juniores a seniores. No entanto, também acho que não deve ser o local para encontrar grandes quantidades de problemas - mesmo para os juniores.

Alguém está lutando para conseguir que os desenvolvedores atinjam o objetivo de "Minha solicitação de recebimento deve estar pronta para produção"?

Riaan Schutte
fonte

Respostas:

13

Não. As solicitações pull não são o local para treinamento. Sua equipe tem a ideia certa. Um PR significa "Eu acho que é bom ir. Posso ter um segundo par de olhos nisso, caso eu perca alguma coisa. Eu sou humano, afinal." E suspeito que é exatamente o que seu aprendiz está fazendo. Eles honestamente acham que é bom ir.

Aqui está uma idéia extrema (trocadilhos). Emparelhe o programa com o aprendiz que está lhe dando azia. Como um membro da equipe mais sênior, é seu trabalho elevá-los e torná-los produtivos.

Pato de borracha
fonte
Obrigado @RubberDuck. O programa de pares é uma ótima idéia e estamos fazendo isso - meio que. Eu suspeito que deveríamos estar fazendo isso mais. No entanto, algumas métricas ou ferramentas adequadas para medir se uma de suas "quedas" no oceano está repetidamente cometendo os mesmos erros ajudariam a saber quem também precisa dessa programação em pares. Tenho certeza de que esse problema piora com equipes maiores !?
Riaan Schutte
2
Bem, eu argumentaria que todos nós precisamos emparelhar a maior parte do tempo. Um de nossos aprendizes capturou mais do que alguns dos meus erros e sou um dos mais graduados da equipe. Você provavelmente poderia consultar o número de comentários sobre solicitações de recebimento, mas eu não o recomendaria. Algo sobre indivíduos e interações ... Sério, porém. É seu trabalho elevar esse desenvolvedor. Pegue uma cópia do Clean Code ou algo assim.
precisa
1
Em um local de trabalho em que todos os desenvolvedores estão trabalhando no trabalho citado para um cliente (nenhum projeto interno que se financia) a programação de pares não é tão fácil, mas continua sendo importante! Parece algo em que a empresa pode apenas ter que investir e investir se quisermos desenvolvedores mais produtivos no trabalho citado.
Riaan Schutte
1
Hmm ... por que não é assim tão fácil? O cliente não recebe tantas horas de trabalho e, mais importante, um valor melhor pelo dólar? Boa sorte, companheiro. Acalme-se com a criança.
precisa
3
Esse é um equívoco comum @Andy. Mas não é verdade. Sim, é contra-intuitivo, eu sei.
precisa
9

Se o código que viola os principais princípios ou padrões de design da equipe chega ao estágio de solicitação de recebimento, ele deve ser definitivamente abordado lá. E as revisões de código podem ser um bom meio de comunicar os padrões e as práticas de design da equipe.

Mas é o melhor lugar? Aqui estão algumas razões pelas quais eu diria que não:

  1. Se forem necessárias várias iterações de revisão de código para solucionar uma falha fundamental de design ou um problema de larga escala, haverá uma forte tentação de ignorar os problemas mais pequenos mencionados acima, devido a prazos ou esgotamento geral da revisão. Idealmente, a equipe seria resiliente o suficiente para resistir a essa tentação, mas provavelmente é melhor não criar uma situação que a levaria.
  2. Receber uma revisão de código com um grande número de comentários não é uma ótima experiência para um desenvolvedor júnior / novo contratado. Sim, responder ao feedback é uma habilidade que eles precisam desenvolver, mas também é verdade que os desenvolvedores nem sempre são hábeis em responder com tato ao código que não gostam.

A programação em pares e as revisões de projeto são locais preferíveis para feedback em escala maior.

Dito isso, seria ainda pior deixar o código passar por medo de que o endereço durante a revisão do código esteja "errado" e pode haver algumas circunstâncias (por exemplo, equipes remotas) em que isso é o melhor que você pode fazer. Nesse caso, resolva os problemas na revisão de código e também os problemas em seu processo de desenvolvimento que chegaram até aqui.

Embora encontrar o problema durante uma solicitação pull não seja o ideal, é certamente melhor do que em um teste ou em um problema de produção.

JohnMcG
fonte
5

Eu diria isso mais, pois solicitações pull não devem ser o único lugar para treinar pessoas. Além disso, os desenvolvedores juniores não são os únicos que podem precisar de algum treinamento em uma solicitação pull. Empreiteiros, colaboradores de código aberto, desenvolvedores de outros departamentos que não estão familiarizados com o código ou padrões locais, e mesmo programadores veteranos precisam de lembretes ocasionais quando se tornam complacentes.

Há muito pouco custo para manter uma solicitação de recebimento aberta por um tempo. Dê o feedback que você quiser com a quantidade de pessoas que desejar, e deixe em paz até que os autores notifiquem você novamente que eles acham que está pronto para a fusão. Uma solicitação de recebimento é uma ótima ferramenta central para se comunicar sobre alterações de código propostas, estejam elas prontas ou precisando de muito trabalho.

Algumas revisões de solicitações de recebimento são pouco mais que um carimbo de borracha, e algumas que são envios externos a uma equipe podem levar um mês para frente e para trás. O primeiro tipo é bom quando você pode obtê-lo, mas isso não significa que o segundo tipo não seja valioso. Tentar levar as pessoas a enviar solicitações perfeitas o tempo todo será frustrante para todos.

Karl Bielefeldt
fonte
Obrigado pela sua resposta @ Karl-Bielefeldt. Concordou que se pode esperar algum treinamento, mas a questão é quanto é apropriado, em que nível. Sua declaração "... se eles estão totalmente prontos ou precisam de muito trabalho". Eu diria que um PR para dominar nunca deve precisar de muito trabalho. Muito trabalho implica falhas de design, falhas de implementação, em vez de me ajudar a identificar o que eu perdi. No entanto, concordo e experimentei "Tentar levar as pessoas a enviar solicitações perfeitas o tempo todo será frustrante para todos".
Riaan Schutte
2

Sempre achei que uma das características de um bom lead é alguém que fornece o treinamento adicional conforme necessário durante cada ciclo de desenvolvimento. Para mim, isso significa que não estou apenas me codificando ou revisando o código, mas sentado com mais desenvolvedores juniores, emparelhando a programação com eles para ajudá-los a evitar o tipo de minas terrestres em que pisei.

Principalmente, não tenho ilusões de que nosso objetivo principal seja educacional - não é. Seja você um desenvolvedor sênior, líder ou júnior, o objetivo não é a sua edificação. O objetivo é sempre entregar código de qualidade ao cliente. De preferência no prazo, dentro do orçamento, fazendo o que eles querem. Reconheço, no entanto, que é impossível para mim realizar todo o trabalho sozinho, por isso cabe a mim como um líder ajudar todos a ajudar a equipe a ter sucesso. E isso significa reconhecer oportunidades de treinamento quando elas aparecerem na natureza.

Portanto, para sua pergunta sobre se as solicitações pull são o local ideal para o treinamento de juniores, eu diria que não é incomum que momentos de aprendizado possam surgir durante elas. Ei, você terá que lidar com seu primeiro conflito de mesclagem, vamos analisar isso após a revisão. Olha, você não incluiu nenhum teste de unidade para o seu DAO, adiaremos sua revisão até que tenhamos a chance de abordar esses novos métodos. Por que você achou que seria melhor usar primitivas duplas nesse cálculo financeiro do que BigDecimals? Sim, isso não é realmente incomum.

Então, enquanto eu diria que isso certamente pode acontecer, mas claramente não é o objetivo principal de uma solicitação pull. Também não sinto que haja uma expectativa de que o código em uma solicitação pull esteja pronto para produção. Muitas vezes não é.

Se você estiver usando ramos de recursos e liberações em uma estratégia de ramificação no estilo gitflow, suas solicitações de recebimento se tornarão mais parecidas com candidatos a lançamento. Não está pronto para produção, mas algo mais aproximado. Você conhece seu código compilado (à direita) e possui cobertura de teste suficiente para fazer uma afirmação decente de que ele atende aos objetivos da história do usuário. E como você já executou vários testes de integração em seu ambiente de desenvolvimento, você tem uma ótima demonstração pronta para ser solicitada a demonstrar suas alterações, o que você fará durante a revisão do seu PR.

Por fim, acho que deveríamos prestar assistência durante as revisões do PR, mas essa assistência não está relacionada à codificação geral. Em vez disso, está associado à preparação do código proposto para inclusão em uma base de trabalho de código de qualidade da produção. O PR é uma oportunidade para os desenvolvedores demonstrarem que têm uma justificativa e uma sólida compreensão de cada alteração incluída no PR. E mesmo assim - mesmo depois de os pesarmos com testes de unidade, demos e muitas perguntas - ainda não há expectativa de que as alterações propostas estejam prontas para produção.

O código está fechado depois de tudo isso. Mas então deixamos o controle de qualidade torturá-lo.

Michael Peacock
fonte
Obrigado pela sua resposta @ Michael-Peacock. O que você diz parece verdadeiro para empresas que têm um departamento de controle de qualidade separado ou testadores que o levam para a próxima fase. Mas quando os desenvolvedores também testam, o PR acompanha tudo, desde o desenvolvimento até o teste e a fusão com o master. Nesse fluxo de trabalho, o código precisa estar pronto para produção depois que o PR for aprovado. Suponho que a pergunta também seja carregada com uma suposição sobre qual fluxo de trabalho você está usando.
Riaan Schutte
Eu diria que, mesmo que você não tenha uma equipe de controle de qualidade dedicada, é ainda mais importante garantir que você inclua testes de integração e / ou aceitação em seu fluxo de trabalho, além de permitir tempo para um possível retrabalho, caso o código mesclado falhe nos testes. Você pode automatizar alguns dos testes de aceitação usando Selenium e Cucumber para diminuir a carga dos desenvolvedores, mas acho importante não assumir que o código esteja pronto para produção até que você o demonstre através de testes.
Michael Peacock
Concordo plenamente, portanto, por que todo o código requer os testes associados a ele. Se você, em seguida, refazer o master antes da mesclagem, pode ter certeza de que os testes passam e o código deve funcionar conforme o esperado.
Riaan Schutte
2

Quero agradecer a todos por sua contribuição e por me ajudarem a entender o que as pessoas têm a dizer sobre este tópico.

Esta é a minha resposta após o feedback fornecido e meu entendimento agora com base nas respostas e comentários recebidos. Obrigado a todos.

Sumário

  • Não esperar ou impor pedidos de tração perfeitos do bastão, pois isso só se tornará frustrante para todos os envolvidos.
  • Mas continue a ser nosso objetivo para obter solicitações de pull perfeitas.
  • Espere uma certa colaboração / assistência em solicitações de recebimento. Afinal, é isso que você está solicitando essencialmente, criando uma solicitação de recebimento.
  • Se ficar um pouco demais devido a falhas de design ou implementação, gaste tempo com esse desenvolvedor e faça alguma Programação em pares para construí-las e aproximar seu código da meta . Esse é o papel de todos os desenvolvedores seniores.
  • Os juniores precisarão de mais sessões de programação em pares do que os desenvolvedores intermediários. Portanto, espere solicitações pull para refletir esse requisito.
  • Incentive os desenvolvedores a realizar reuniões de design / implementação antes de tocar no código para reduzir qualquer retrabalho identificado em Pull Requests.
Riaan Schutte
fonte
1
Resumo maravilhoso e resposta. Eu não ficaria ofendido se você se desse a marca de seleção.
precisa
Obrigado @RubberDuck, mas meu resumo não poderia existir sem as respostas e os comentários de todos à minha pergunta. Felicidades.
Riaan Schutte
0

Você pode dizer mais sobre a cultura da sua empresa em termos de equipes técnicas? Se você está lutando com a idéia de o código estar pronto para produção quando um desenvolvedor deseja se unir à linha principal, o que você realmente está dizendo aos seus desenvolvedores? Você está dizendo a eles que quando o trabalho deles está "pronto", tudo bem se não funcionar? Tudo bem se isso quebrar o sistema? Se eles estão adicionando dívida técnica, talvez esteja tudo bem se eles puderem justificá-la e estiverem cientes do que estão fazendo, e mostrar que podem voltar e refatorar mais tarde. Mas se eles não sabem por que estão fazendo algo perigoso, quantas vezes você vai deixar passar?

Se você tem um desenvolvedor júnior, os primeiros pedidos de recebimento obviamente terão problemas. Eventualmente, eles deveriam pegar o jeito. Se você perceber que eles continuam tendo problemas, poderá atribuir um trabalho para o qual ainda não estão prontos?

Ou talvez você precise contratar um substituto júnior e demitir o que não foi capaz de descobrir isso?

Você sabe o que eu vi? Pessoas que não são desenvolvedores competentes continuam a trabalhar em uma empresa há anos apenas por causa do nepotismo. Portanto, é claro que suas solicitações de recebimento exigem várias revisões. Na linguagem Lean, eles são "desperdícios" - uma chatice na equipe e uma chatice na linha de fundo.

Então você tem que decidir por si mesmo: quantos pedidos de puxar serão necessários para seus juniores mostrarem competência e você tem a coragem de deixar de lado aqueles que não o fazem?

RibaldEddie
fonte
Obrigado por você responder a @RibaldEddie, esperamos que os desenvolvedores escrevam testes de unidade, testem manualmente e revisem seu próprio trabalho a ponto de afirmarem que esse código é ótimo e, se lhes restar, eles o mesclariam no master, mas dois revisores o revisarão e espero confirmar essa afirmação. Não aceitamos nenhuma dívida técnica e estamos nos afastando totalmente das correções em favor das soluções. Portanto, a expectativa é que o código atenda a esses requisitos.
Riaan Schutte
@Riaan, quem são os revisores?
RibaldEddie
Qualquer pessoa técnica leva a juniores. Normalmente, é um revisor sênior / intermediário junto com um revisor júnior / intermediário. (2 revisores)
Riaan Schutte
@Riaan, então, com o tempo, eu esperaria que os membros juniores da equipe se diferenciassem. Você será capaz de dizer quem é consciente e quem é ofensivo. Acho que o desenvolvimento de software bem feito é uma atividade adequada a uma mentalidade orientada a detalhes. Algumas pessoas podem não ser capazes de fazer isso. Você precisará decidir o que fazer com eles. Mas, fundamentalmente, você deve esperar que os desenvolvedores que enviam o código sejam mesclados tenham certeza de que ele funciona conforme o esperado e está pronto para produção. Mesmo se você tiver uma equipe grande e sofisticada de controle de qualidade, seus desenvolvedores ainda devem estar usando o código pronto para produção.
RibaldEddie