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.