Como incentivar desenvolvedores juniores a participar da revisão de código?

Atualmente, estou trabalhando como desenvolvedor sênior com três juniores abaixo de mim e introduzimos um processo de revisão de código para ajudar a gerenciar a qualidade do código que entra em produção.

Sinto que é muito benéfico para todos nós revisarmos o trabalho uns dos outros, no entanto, após cerca de 5 semanas do processo, sou o único a fazer comentários na ferramenta (BitBucket).

Eu acho que existem algumas questões culturais em ação, e talvez uma relutância natural no caso de seus comentários estarem errados, mas existe alguma maneira e eu posso ajudar os juniores a se sentirem mais à vontade criticando os meus e os outros trabalhando?

Para mim, a pergunta aqui é "o que você está procurando que seus desenvolvedores juniores tirem das revisões de código?". Para mim, potencialmente a coisa mais importante é que os desenvolvedores juniores aprendam observando o que é esperançosamente um bom código; se eles encontrarem problemas no seu código também, isso é um bônus.

Se você está procurando que sua equipe júnior aprenda com as revisões de código, a coisa mais importante a fazer é criar um ambiente em que a aprendizagem seja valorizada e não vista como uma perda de tempo. Isso significa várias coisas:

• Não existe uma pergunta estúpida . Se alguém não entende um pouco de código, por que você usou um determinado padrão ou o que quer que seja, ele precisa ficar à vontade para perguntar, sem nunca sentir que está desperdiçando seu tempo ou o dos outros desenvolvedores .
• Tempo gasto aprendendo é tempo bem gasto . Você deseja que seus desenvolvedores juniores passem algum tempo analisando o código e aprendendo com ele, porque isso os tornará uma equipe melhor e mais produtiva no futuro. A menos que seja uma correção crítica que precise ser revisada agora , incentive-os a gastar mais, e não menos, tempo nas revisões de código.
• Os funcionários seniores nem sempre estão certos . Só porque você faz isso há mais tempo não significa que você está certo. Se eles acham que encontraram um bug, provavelmente estão certos. Se eles acham que outro padrão de design seria apropriado para esse trecho de código, precisam se sentir à vontade para dizê-lo sem obter feedback negativo.

Realize reuniões de revisão de código pessoalmente em horário definido toda semana. Eu vendi isso para meu colega de equipe dessa maneira (na verdade, somos ambos desenvolvedores seniores, mas tanto faz):

"A revisão do código está parcialmente lá para eu conhecer um pouco melhor o seu código e saber o que está acontecendo do seu lado, caso você seja atropelado por um caminhão algum dia e eu recebo ordens para terminar o seu sprint. Mas principalmente é lá para você explicar seu código a outra pessoa, porque quando você faz isso, ele envolve uma parte diferente do seu cérebro, e muitas vezes sua explicação para eles e / ou suas perguntas ou comentários podem fazer com que você se lembre de algo que esqueceu executar no código ou pode fazer com que você perceba uma maneira melhor de torná-lo mais legível ou de arquitetá-lo melhor. Isso leva a um código mais bonito ".

Eu gosto de pensar nisso como um show-and-tell. As pessoas podem mostrar seu trabalho para seus colegas. Não se trata de seus colegas encontrarem coisas erradas em seu trabalho, das quais ninguém gosta. Trata-se de impressionar seus colegas com seu código incrível, do qual todo mundo gosta.

No entanto, acho que o uso de ferramentas de revisão de código onde não há interação humana, nenhuma reunião em uma sala, nenhum quadro branco ... torna-se apenas mais uma "coisa" irritante a ser feita. Não é que não devam existir essas ferramentas, mas elas devem ser algo a que você recorre se, durante a reunião de revisão de código, perceber que pode ser necessária uma revisão mais aprofundada de uma determinada seção do código. Em seguida, você pode designar um dos desenvolvedores juniores para revisar o código do outro em uma determinada área.

Você pode ajudar dando um bom exemplo. Você não pode ficar na defensiva quando alguém aponta seus erros. Faça uma revisão de código em seu próprio código e observe as áreas de melhoria. Compartilhe isso com a equipe. Eventualmente, eles aprenderão que isso é incentivado e ninguém receberá uma surra por ter um bug em seu código.

Ter um emprego significa assumir responsabilidade e orgulho no seu trabalho. Se a revisão de código fizer parte disso, a participação na revisão de código deve ser incluída nas avaliações. Participei de aulas on-line nas quais a participação em discussões on-line faz parte da nota. Os comentários precisam ser elaborados em. "Eu concordo" não é aceitável.

A revisão de código deve melhorar o código. Dependendo da sua situação, pode ser medido por números de vendas, reclamações de usuários ou alguma outra classificação, se você escrever um código para uso interno. A realidade é que seu código serve a algum propósito e sua equipe deve ser medida pela qualidade em que eles servem. Aqueles que você determinar contribuem para o sucesso, compartilham proporcionalmente as recompensas.

Concentre-se em liberar código de qualidade. O objetivo não é que todos se sintam bem consigo mesmos, evitando os bugs. Eu escrevo código ruim; Eu tenho que corrigir o código incorreto. Isso é trabalho e vida. Eu odeio consertar bugs, então tento evitá-los. Tenho orgulho do meu trabalho, por isso me incomoda quando meu código não funciona. Sinto-me mal pelos usuários ou por qualquer outra pessoa que precise dedicar algum tempo para apontar essas coisas e isso me motiva a querer corrigi-las.

Como observação lateral, se você tem um ambiente em que ninguém pode dar ou aceitar críticas construtivas, você tem um problema.

O processo: alguém quer confirmar suas alterações. Alguém é designado como revisor e revisa as alterações. Em seguida, as alterações revisadas e corrigidas vão para o teste.

Se o teste encontrar erros introduzidos na alteração, autor e revisor são os culpados.

Ao fazer uma revisão sem comentários, você terá problemas, a menos que o código seja perfeito.