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

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

Como exemplo, se um aplicativo está sendo desenvolvido em Python e o engenheiro júnior tem 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 de fazer algo. , mas eles também podem 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 na indústria financeira, pode ser ajudado por ter um desenvolvedor menos experiente, com apenas 5 anos de experiência, todos no setor financeiro, revisando seu trabalho.

Convidar funcionários menos experientes para 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 se espera deles não apenas em revisões de código, mas no código que eles produzem. No entanto, você provavelmente não quer envolver muitas pessoas (concentrando-se nas pessoas que podem apoiar totalmente a revisão do código e seu propósito) no processo.

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

Should junior programmers be involved as code reviewers in the projects of senior programmers?

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 espere que o código de um desenvolvedor sênior não seja ruim ...)

Obviamente, é insensato somente ter juniors fazendo a revisão de código. E imprudente colocar expectativas muito altas sobre os juniores em termos do que eles podem encontrar. No entanto, você também pode se surpreender com os novos insights que os programadores juniores podem trazer para a mesa.

Outra Resposta mencionou os juniores sendo / sentindo-se intimidados. NÃO é isso que a revisão de código deve ser ... sobre o revisado ou os revisores. Se isso está acontecendo, o seu grupo precisa mudar a maneira como o código analisa ... e talvez os intimidadores precisem ser alinhados.

Gostaria de acrescentar que, se um programador "Junior" puder não entender um código sênior, 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 esperamos que sejam exceções - se apenas 1 ou 2 pessoas puderem entender o código, o que acontece quando essas pessoas não estão disponíveis e há um problema com isso?

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

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

A finalidade das revisões de código é detectar problemas que os testes não conseguem detectar, como problemas de manutenção e casos de canto. Eu diria que, em muitos aspectos, os programadores juniores são melhores para esse fim:

• Eles têm mais tempo disponível em geral.
• É mais provável que eles façam isso lentamente, linha por linha, por necessidade de entender o código.
• Quando você fala sobre o código ser sustentável, isso significa que todos na empresa, não apenas seus principais programadores. Isso significa que seus programadores juniores devem entender o código para declará-lo sustentável.
• Eles são menos propensos a fazer suposições ruins, confiando que algo funciona da maneira que eles acham que deveria funcionar.
• A educação deles em uma linguagem de programação é mais recente, e menos provável de ser confundida com anos de experiência em outro idioma. Por exemplo, um idoso pode acidentalmente usar um hábito que ele pegou no C ++ que compila, mas funciona de maneira sutilmente diferente em Java. Os juniores captam esses tipos de erros com mais facilidade.
• Os revisores de código só precisam identificar problemas, não necessariamente propor uma solução melhor. Eles costumam fazer comentários ao longo das linhas: "Eu não consigo descobrir como fazer melhor, mas esta parte é realmente confusa por causa de toda a repetição." Um programador mais experiente pode, então, fazer facilmente as melhorias, mesmo que elas não tenham percebido o problema no início.

Isso não quer dizer que não haja outras maneiras pelas quais os programadores seniores sejam mais adequados para fazer avaliações, mas meu ponto é que você está fazendo um desserviço se não estiver aproveitando ao máximo a diversidade de sua equipe.

Frequentemente, os juniores são solicitados a manter o código, é fundamental que eles possam entendê-lo.

Às vezes, as 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ós não pressionamos nada do dev sem uma revisão de código e eu estou assumindo esse tipo de revisão de código também) porque o chefe do senior está de férias?

Eu também pedi especificamente aos juniors para fazer uma revisão de código quando soube que eles estariam fazendo algo semelhante para um cliente diferente em breve ou se eu soubesse que eles tinham trabalhado em algo mais semelhante ou que eles tinham um conjunto de habilidades em particular.

Se o código é bastante simples, muitas vezes eu tenho uma pessoa mais nova para fazer a revisão. Por que desperdiçar o tempo da pessoa idosa se a pessoa mais nova é capaz de fazer o trabalho? Se os juniores se sentirem intimidados pela revisão do código do senior, faça com que eles vejam as peças mais fáceis inicialmente. Afinal, você não pode deixar de ser junior até parar de se sentir intimidado.

Descobri frequentemente que, se tiver de explicar o código a uma pessoa júnior que não o compreenda, verei um erro que cometi (normalmente numa hipótese) e que nenhum revisor de código experiente teria apanhado porque o código é executado mas não faz exatamente o que foi planejado. Assim, apenas o ato de explicar as coisas geralmente ajudará o desenvolvedor a ver um problema sem que o revisor de código o encontre. Uma vez que as pessoas mais experientes não são muitas vezes tomadas através do 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 o júnior envolvido em resenhas tem vários efeitos positivos. Primeiro, torna-os mais confiantes quando conseguem entender o código de uma pessoa idosa. Isso os torna ainda mais confiantes quando eles podem encontrar um bug nesse código.

Os expõe a processos de pensamento fora dos seus e os deixa ver outras formas de lidar com as coisas. Mesmo como uma pessoa sênior, isso aconteceu comigo - ver uma maneira diferente de resolver um problema pode ser um abridor de olho 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 está longe ou está ocupado em outro projeto e não tem tempo para perguntas.

É bom para os idosos porque as duas perguntas expõem áreas potenciais nas quais os juniores são fracos e precisam de orientação (para que possam assumir mais responsabilidade e dar aos idosos mais tempo para realizar outros tipos de tarefas) ou áreas onde o código é simplesmente Não é claro para ninguém, exceto o autor (o que significa que pode até não ser claro para o autor daqui a um ano quando ele precisa ser alterado). Também ajuda os idosos a perceberem que os juniores podem ser mais espertos do que aqueles que lhes deram crédito por estarem. Isso ajuda a manter todos em pé de igualdade. Afinal, se você exclui juniors, então você está claramente sugerindo que você não acha que eles são capazes de entender o código que é psicologicamente infeliz.

Os juniores que revisam o código dos seniores podem gerar mais respeito profissional em sua organização. Os idosos podem perceber que estão subestimando os juniores e os juniores que podem perceber que os idosos sabem mais do que eles acreditavam. Os juniores às vezes acham que eles têm mais habilidades do que eles. Estar exposto a códigos que eles não podem escrever é bom para essas pessoas porque elas começam a perceber que têm muito mais a aprender. Ele também irá estimular o melhor deles para obter as habilidades. Na escola, às vezes, os alunos B não entendem por que não receberam um A até que alguém os mostre uma amostra do nível de trabalho A. Mesmo com juniors para idosos na revisão de código.

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

Para:

• Se você quiser que os juniores aprendam como fazer uma revisão de código eficaz, a melhor maneira é que eles vejam como os idosos fazem isso.
• Um programador júnior pode ter mais experiência do que um sênior em um determinado idioma / domínio / etc.
• Forçando os juniores a avaliar o código dos idosos, eles vão inevitavelmente aprender coisas. A programação em pares será uma maneira mais eficaz de fazer isso, já que 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 seja revisado. Se você não fizer isso, quem vai rever o código de seus principais caras?
• Nem todos os juniores são iguais e nem todos os seniores são iguais. Às vezes pode não haver muita lacuna, então não fique preso em cargos.

Contra:

• Existe o risco de os comentários serem atolados por não-problemas de juniores.
• O nível de conhecimento / habilidade necessário pode simplesmente ultrapassar as capacidades do júnior. Isso vai não apenas desperdiçar seu tempo, mas também, possivelmente, desmoralizá-los também.

Acredito firmemente que todos na equipe devem estar envolvidos em ambos os lados das revisões de código. Os juniores devem rever o código sênior e vice-versa. Por que ambos? Porque geralmente não é apenas sobre se o código é "resolve o problema". Eu não posso te dizer quantas vezes eu tive que explicar um pedaço de código para alguém e de repente chegar a uma maneira muito melhor de fazê-lo até o final da explicação. As revisões de código servem provavelmente a três propósitos:

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

Sou júnior e geralmente reviso o código sênior escrito. É uma política geral da empresa "tudo fica código revisado por alguém". Eu aprendo muito com estes 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 clara de fazer um certo 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 as suas revisões de código. As nossas são muito informais e consistem em "ei, olhe para o meu código", sendo dito em cubículos ou em um canal privado de IRC. Eu poderia imaginar que, se você revisasse o código em um ambiente mais formal, o júnior provavelmente ficaria muito mais intimidado sobre a revisão do código de um veterano.

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

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 não percebe, seja o revisor sênior ou júnior; o revisor nem precisa ser humano . É muito comum, por outro lado, que o codificador original reconheça um erro ao tentar explicar o código, e quanto mais júnior o revisor, mais provável é que isso ocorra, devido à profundidade necessária de explicação.

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

• Compartilhando conhecimento do que realmente está acontecendo na base de código - "Espere, acho que Bill tinha uma classe que faz X, não precisamos escrever uma nova."
• Compartilhando conhecimento 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 sênior.

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

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

Há uma infinidade de benefícios:

• O autor será forçado a explicar mais seu código. Falar com seu código é uma das melhores formas de encontrar problemas ou melhores formas de o fazer

• O autor encontrará pontos fracos em seu código. O desenvolvedor júnior é mais provável de ser confundido por alguns dos trechos mais avançados. Freqüentemente, eles são "muito complicados" para seu próprio bem e podem se beneficiar da simplificação.

• O desenvolvedor júnior aprenderá práticas de codificação melhores. As revisões de código são uma oportunidade para 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 estiver com revisões de código, mais rápidas e efetivas serã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 júnior no início, você poderá entregá-los a eles 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 negligenciado das revisões de código.

• O desenvolvedor júnior é um novo jogo de olhos. Eles não são tão doutrinados quanto alguém que trabalha na base de código por um longo período de tempo. É mais provável que o desenvolvedor júnior aponte maneiras diferentes de realizar as coisas enquanto fazem perguntas. Não se esqueça dos comentários mais cruéis sem pelo menos alguma consideração!

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

A desvantagem a considerar é que todas as partes envolvidas gastarão um bom tempo realizando revisões de código. Assim, pode ser difícil 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 aprendizado. Se eu fosse um programador júnior, ficaria intimidado em rever o código do senior.

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

Duas alternativas poderiam ser:

• deixe que os juniores participem de reuniões de revisão de código e que todos os atendentes estejam abertos a algumas discussões de ensino / aprendizagem
• programação em par de prática