Os programadores juniores devem ser envolvidos como revisores de código nos projetos dos programadores seniores?

Um dos membros da minha equipe, um programador júnior, possui habilidades de programação impressionantes para seu nível de experiência.

E durante as revisões de código, acredito em enfatizar o aprendizado, sem apontar erros.

Mas os programadores juniores devem se envolver em revisões de código para programadores seniores? Ou as revisões de código devem ser assistidas apenas por programadores com a experiência correspondente?

O principal objetivo de uma revisão de código é encontrar defeitos ou possíveis problemas. Os participantes exigidos na revisão devem ser as pessoas mais adequadas para identificar esses problemas, independentemente de seu título ou antiguidade.

Por exemplo, se um aplicativo estiver sendo desenvolvido em Python e o engenheiro júnior tiver mais experiência com a linguagem Python do que o engenheiro sênior que escreveu o código, eles podem ser um recurso valioso ao apontar métodos alternativos para fazer algo, mas eles também pode ter menos conhecimento do sistema como um todo.

Além da experiência nas ferramentas e tecnologias, considere também a experiência no domínio do aplicativo. Alguém com 20 anos de experiência, mas apenas 1 ou 2 no setor financeiro pode ser ajudado por um desenvolvedor menos experiente, com apenas 5 anos de experiência no setor financeiro, revisar seu trabalho.

Convidar funcionários menos experientes a observar e participar o máximo possível do processo de revisão de código também pode ser benéfico para permitir que eles aprendam uma base de código, façam perguntas e aprendam sobre o que é esperado deles não apenas nas revisões de código, mas também no código que eles produzem. No entanto, você provavelmente não quer muitas pessoas envolvidas (concentrando-se nas pessoas que podem apoiar totalmente a revisão do código e seu objetivo) no processo.

Isso realmente se aplica a qualquer tipo de revisão - requisitos, design, código ...

Os programadores juniores devem ser envolvidos como revisores de código nos projetos dos programadores seniores?

Sim eles deveriam. É uma boa experiência de aprendizado ler o código de outras pessoas. (E isso se aplica tanto ao código bom quanto ao ruim. Embora se esperasse que o código de um desenvolvedor sênior não fosse ruim ...)

Obviamente, é imprudente ter apenas juniores fazendo a revisão do código. E imprudente colocar expectativas muito altas para os juniores em termos do que eles podem encontrar. No entanto, você também pode se surpreender com as novas idéias que os programadores juniores podem trazer para a mesa.

Outra resposta mencionou os juniores sendo / se sentindo intimidados. Não é disso que se trata a revisão de código ... para os revisados ​​ou para os revisores. Se isso estiver acontecendo, seu grupo precisa mudar a maneira como faz suas revisões de código ... e talvez os intimidadores precisem ser alinhados.

Eu acrescentaria que, se um programador "Junior" não conseguir entender um código para idosos, isso por si só é uma boa medida do código. OK, pode haver momentos em que simplesmente não é possível escrever código que todos possam entender, mas espero que sejam exceções - se apenas 1 ou 2 pessoas conseguem entender o código, o que acontece quando essas pessoas não estão disponíveis e há um problema com isto?

Dar às pessoas novos desafios as ajuda a se desenvolver; também pode ser que nem todo mundo esteja preparado para revisar o código, mas parece dogmático insistir que alguém tenha um título ( determinado pela política e jogos de RH ) antes de ser elegível para ajudar em uma revisão.

Como outros salientaram, uma revisão de código pode ser um processo bidirecional; ajuda a todos a entender a base de código, compartilha o conhecimento, ajuda os juniores a aprender maneiras e técnicas novas e melhores de seus idosos e ajuda os idosos a refinar sua compreensão e escrevendo para garantir que todos possam seguir o código que você tem mais olhos que podem pegar erros.

O objetivo das revisões de código é detectar problemas que os testes não podem detectar, como problemas de manutenção e casos extremos. Eu argumentaria que, de várias maneiras, os programadores juniores são mais adequados para esse propósito:

• Eles têm mais tempo disponível em geral.
• É mais provável que eles andem devagar, linha por linha, por necessidade de entender o código.
• Quando você fala sobre a manutenção do código, isso significa que todos na empresa, não apenas seus principais programadores. Isso significa que seus programadores juniores devem ser capazes de entender o código para declará-lo como sustentável.
• Eles geralmente são menos propensos a fazer suposições ruins, confiando que algo funciona da maneira que eles supõem que deve funcionar.
• Sua educação em uma linguagem de programação é mais recente e menos provável de ser confundida com anos de experiência em outra linguagem. Por exemplo, um idoso pode usar acidentalmente um hábito que adquiriu do C ++ que compila, mas funciona sutilmente diferente em Java. Os juniores percebem esses tipos de erros mais facilmente.
• Os revisores de código precisam apenas identificar problemas, não necessariamente propor uma solução melhor. Eles costumam fazer comentários como "Não consigo descobrir como fazê-lo melhor, mas essa parte é realmente confusa por causa de toda a repetição". Um programador mais experiente pode facilmente fazer as melhorias, mesmo que não tenha percebido o problema no início.

Isso não quer dizer que não há outras maneiras pelas quais os programadores seniores são mais adequados para fazer revisões, mas o que quero dizer é que você está prestando um desserviço se não estiver aproveitando ao máximo a diversidade da sua equipe.

Os juniores serão frequentemente solicitados a manter o código, é fundamental que eles possam entendê-lo.

Às vezes, os juniores são as únicas pessoas disponíveis para revisar o código dos desenvolvedores seniores. O código deve esperar para ir para o controle de qualidade (não tiramos nada do desenvolvimento sem uma revisão de código e estou assumindo esse tipo de revisão também) porque o chefe do sênior está de férias?

Também pedi especificamente aos juniores que revisassem códigos quando soubessem que em breve estariam fazendo algo semelhante para um cliente diferente ou se soubessem que haviam trabalhado em algo que era semelhante ou que tinham um conjunto de habilidades em particular.

Se o código é bastante simples, geralmente recebo uma pessoa júnior para fazer a revisão. Por que desperdiçar o tempo do idoso se ele é capaz de fazer o trabalho? Se os juniores se sentirem intimidados ao revisar o código dos idosos, peça-lhes que examinem as peças mais fáceis inicialmente. Afinal, você não pode deixar de ser júnior até parar de se sentir intimidado.

Descobri muitas vezes que, se eu tiver que explicar o código a uma pessoa que não o entende, vou ver um erro que cometi (geralmente em uma suposição) e que nenhum revisor de código experiente teria capturado porque o código é executado mas não faz exatamente o que foi planejado. Portanto, apenas o ato de explicar as coisas ajudará o desenvolvedor a ver um problema sem que o revisor de código o encontre. Como as pessoas mais experientes não costumam ler o código passo a passo, esses tipos de coisas são encontrados mais facilmente quando um júnior faz a revisão.

Acho que ter participado de júnior em revisões tem vários bons efeitos. Primeiro, eles ficam mais confiantes quando conseguem entender o código de uma pessoa idosa. Isso os torna ainda mais confiantes quando podem encontrar um bug nesse código.

Ele os expõe a processos de pensamento exteriores aos seus e permite que eles vejam outras maneiras de lidar com as coisas. Mesmo como pessoa idosa, isso aconteceu comigo - ver uma maneira diferente de resolver um problema pode abrir os olhos para novas possibilidades.

Isso os ajuda a aprender a ler o código de outras pessoas e dá a eles a chance de perguntar o que o código está fazendo enquanto ainda está fresco na mente do autor. Isso é muito melhor do que ter que manter a coisa seis meses depois, quando o autor se foi ou está ocupado em outro projeto e não tem tempo para perguntas.

É bom para os idosos, porque as perguntas expõem áreas em potencial em que o júnior é fraco e precisa de orientação (para que possam assumir mais responsabilidades e dar aos idosos mais tempo para realizar outros tipos de tarefas) ou áreas em que o código simplesmente não está claro. qualquer pessoa, exceto o autor (o que significa que talvez nem fique claro para o autor daqui a um ano quando ele precisar ser alterado). Também ajuda os idosos a perceberem que os juniores podem ser mais espertos do que estão dando crédito a eles. Ajuda a manter todos em pé de igualdade com os profissionais. Afinal, se você excluir juniores, está claramente implicando que não acredita que eles sejam capazes de entender o código que é psicologicamente infeliz.

Os juniores que revisam o código dos idosos podem gerar mais respeito profissional em sua organização. Os idosos podem perceber que estão subestimando os juniores e os juniores podem perceber que os idosos sabem mais do que lhes deram crédito. Os juniores às vezes pensam que têm mais habilidades do que têm. Ser exposto ao código que eles não podem escrever é bom para essas pessoas, porque elas começam a perceber que têm muito mais a aprender. Isso também incentivará os melhores a obter as habilidades. Às vezes, na escola, os alunos B não entendem por que não receberam um A até que alguém lhes mostre uma amostra do nível A de trabalho. Mesmo com juniores a seniores na revisão de código.

Minha resposta é: às vezes . Vai variar de programador para programador e de tarefa para tarefa.

Para:

• Se você deseja que os juniores aprendam como fazer uma revisão de código eficaz, a melhor maneira é que eles vejam como os seniores o fazem.
• Um programador júnior pode ter mais experiência do que um programador sênior em um idioma / domínio / etc específicos.
• Ao forçar os juniores a avaliar o código dos idosos, eles inevitavelmente vão aprender coisas. A programação em pares será uma maneira mais eficaz de fazer isso, pois qualquer pergunta que o júnior possa ter pode obter respostas imediatas.
• O código de ninguém é sagrado e ninguém é tão bom que seu código não deva ser revisado. Se você não fizer isso, quem vai revisar o código dos seus melhores?
• Nem todos os juniores são iguais e nem todos os seniores são iguais. Às vezes, pode não haver muita lacuna, portanto, não fique preso nos cargos.

Contra:

• Há o risco de as resenhas serem atoladas com as não questões dos juniores.
• O nível de conhecimento / habilidade requerido pode simplesmente ir além das capacidades dos juniores. Isso não apenas desperdiçará seu tempo, mas possivelmente também os desmoralizará.

Acredito firmemente que todos na equipe devem estar envolvidos nos dois lados das revisões de código. Os juniores devem revisar o código sênior e vice-versa. Por que ambos? Porque geralmente não se trata apenas de saber se o código "resolve o problema". Não sei dizer quantas vezes tive que explicar um pedaço de código a alguém e, de repente, ter uma maneira muito melhor de fazê-lo até o final da explicação. As revisões de código têm provavelmente três finalidades:

1. Verifique se o código está correto
2. Faça o escritor pensar em como os outros verão seu código
3. Obtenha o feedback do leitor sobre o que poderia ser melhorado e um segundo par de olhos geral

Sou júnior e costumo revisar código escrito sênior. É uma política geral da empresa "tudo é revisado por alguém". Aprendo muito com isso, revisando seu código e tendo a oportunidade de fazer perguntas sobre por que as coisas são feitas de uma certa maneira. E, às vezes, proponho uma maneira mais limpa de fazer um determinado pedaço de código e tal. Muito mais raro do que as pessoas me dizendo como melhorar meu código, mas isso aconteceu pelo menos uma vez.

Também importa o quão formal são suas revisões de código. As nossas são muito informais e consistem em "ei, você vai ver meu código" sendo dito em cubículos ou em um canal privado de IRC. Eu poderia imaginar que, se você revisar o código em um ambiente mais formal, o junior provavelmente ficaria muito mais intimidado em revisar o código de um senior.

Absolutamente, os engenheiros juniores devem revisar o código dos engenheiros seniores, pelo menos em parte.

Na minha experiência, é muito raro que o revisor em uma revisão de código individual realmente veja um erro que o codificador original perde, seja o sênior ou o júnior; o revisor nem precisa ser humano . Por outro lado, é muito comum que o codificador original reconheça um erro ao tentar explicar o código, e quanto mais jovem o revisor, maior a probabilidade de isso acontecer, devido à profundidade necessária da explicação.

Alguns benefícios mais frequentemente esquecidos da revisão de código, na minha opinião, são possivelmente mais importantes a longo prazo do que a captura de erros:

• Compartilhando conhecimento do que realmente está acontecendo na base de código - "Espere, acho que Bill teve uma aula que faz X, não precisamos escrever uma nova".
• Compartilhar conhecimentos de boas técnicas e estilo de programação.

Em ambos os aspectos, um revisor júnior tende a se beneficiar mais do que um veterano.

Os programadores juniores devem absolutamente realizar revisões de código para seus colegas seniores!

No entanto, eles não devem ser o único revisor . Associe-os a um desenvolvedor mais experiente por revisão de código.

Há uma infinidade de benefícios:

• O autor será forçado a explicar mais de seu código. Conversar através do seu código é uma das melhores maneiras de encontrar problemas, ou melhores maneiras de fazê-lo.

• O autor encontrará pontos fracos em seu código. O desenvolvedor júnior provavelmente ficará confuso com alguns dos blocos mais avançados. Freqüentemente, elas são "muito complicadas" para o seu próprio bem e podem se beneficiar da simplificação.

• O desenvolvedor júnior aprenderá melhores práticas de codificação. Revisões de código são uma oportunidade de ensinar pelo exemplo.

• O desenvolvedor júnior será um revisor de código mais eficaz. A revisão de código é difícil . Quanto mais experiente é todo mundo com revisões de código, mais rápidas e eficazes são as revisões de código.

• O desenvolvedor júnior terá um conhecimento mais profundo da base de código. Seja egoísta! Ao puxar os desenvolvedores juniores mais cedo, você poderá entregá-los mais cedo.

• O desenvolvedor júnior se sentirá mais envolvido. O desenvolvedor júnior começará a ver o código "sênior" (e seus colegas) como menos estrangeiro e intimidador. Esse é um benefício tremendo e muitas vezes esquecido das revisões de código.

• O desenvolvedor júnior é um novo conjunto de olhos. Eles não são tão doutrinados quanto alguém que trabalha na base de códigos há um longo período de tempo. É mais provável que o desenvolvedor júnior indique maneiras diferentes de realizar as coisas ao fazer perguntas. Não descarte seus comentários mais loucos sem pelo menos alguma consideração!

• Os desenvolvedores seniores são responsabilizados. Eu tenho visto frequentemente situações em que desenvolvedores seniores tendem a encobrir o código um do outro (confiança, preguiça etc.). Um conjunto extra de olhos ajuda a desencorajá-lo.

A desvantagem a considerar é que todas as partes envolvidas passarão um bom tempo realizando análises de código. Portanto, pode ser um pouco difícil de vender para a gerência. Os benefícios superam completamente o ritmo mais lento, no entanto.

Uma revisão de código é feita para revisar o código, não para aprender. Se eu fosse um programador júnior, ficaria intimidado em revisar o código do aluno.

Por outro lado, a leitura do código do idoso é uma ótima maneira de aprender, desde que o idoso esteja disponível para responder a todas as perguntas.

Duas alternativas podem ser:

• permitir que os juniores participem de reuniões de revisão de código e que cada participante esteja aberto a algumas discussões de ensino / aprendizagem
• prática de programação em pares