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?
code-reviews
junior-programmer
mentor
Graham S
fonte
fonte
Respostas:
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:
fonte
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.
fonte
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.
fonte
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.
fonte