No momento, estou revisando alguns dos códigos de desenvolvedores juniores que acabaram de ingressar na minha equipe. Estou pensando em como devo entregar o resultado dessa revisão:
Devo corrigir o código sozinho?
Devo dar a eles feedback sobre o processo de revisão e deixá-los fazer as correções de acordo com minhas instruções? E, em caso afirmativo, como faço para enviar esse feedback, preencho certos documentos de modelo e os envio a eles, ou existe algum software que me ajudará a marcar problemas com os arquivos dos códigos onde eles poderão verificar mais tarde? (Estou usando o Visual Studio).
Depois que eu revisei o código e as correções foram feitas, algum tempo se passou e algumas partes do código que revi no passado foram alteradas. Como faço para rever o processo? Devo verificar novamente todo o código novamente? Ou apenas verifico as peças que foram alteradas? E, em caso afirmativo, como acompanho as partes que foram alteradas para evitar a revisão dupla do código?
fonte
Respostas:
Resposta curta
Não.
Sim. De acordo com suas sugestões , não instruções . As instruções parecem muito autoritárias.
Use uma ferramenta para dar o feedback. Você pode usar o Visual Studio.
Resposta longa
Eu costumava usar o Visual Studio, mas constantemente perguntava a outros desenvolvedores: "Ei, você pode me enviar seu trabalho para que eu possa revisá-lo?" Eu não gostei disso e nunca funcionou muito bem. Agora, uso o Assistente de Revisão porque posso iniciar uma revisão consultando os checkins. Não preciso depender de outro desenvolvedor que me envie trabalho para revisar. Também me ajuda a marcar itens como defeitos, ou simplesmente marcar itens a serem analisados pelo autor. Isso funciona para a nossa equipe porque, quando iniciamos uma revisão, ela permanece no painel de revisão e não se perde na tradução. Isso é integrado ao Visual Studio. Como mencionei, o Visual Studio também tem seu processo de revisão nativo, mas acho que ele tem limitações e o processo não é natural; portanto, eu uso o Assistente de Revisão.
Essa ferramenta também ajuda no processo de vaivém, discussões etc.
O processo, mais ou menos, é o seguinte:
Reviso algo e depois o envio ao autor (no seu caso, junior dev). Eles fazem alterações e depois enviam de volta. Eu olho para as mudanças e forneço feedback. Se eu for bom com as alterações, encerro a revisão. Caso contrário, ele vai e volta. Às vezes, se houver muito de um lado para o outro, vou apenas até a mesa deles e usar um quadro branco - isso realmente acelera o processo.
As revisões de código são uma área sensível, portanto, tenha muito cuidado com a opção de redação. Eu nunca digo a ninguém
Má escolha de redação
Em vez disso, digo o seguinte:
Melhor escolha de redação
Isso faz o autor pensar:
Essas simples escolhas de palavras me ajudaram enormemente.
Eu nunca subestimo desenvolvedores juniores. Eu trabalhei com alguns desenvolvedores seniores (mais de 10 anos de experiência) e o código era pior do que um estudante cooperativo júnior. Então, só porque eles são seniores ou juniores não é tão importante; o trabalho deles é realmente o que fala mais alto do que anos de experiência.
Muitas vezes, para incentivar os desenvolvedores juniores e fazê-los participar das revisões, enviarei algo para eles revisarem para mim: algo que eles possam descobrir, algo que acharão desafiador, mas não totalmente além deles. Posso dizer o seguinte:
Isso me ajuda muito novamente. Isso ajuda porque mostra claramente que eu não sou o único que analisa, mas eles também fazem análises e também fazem parte do processo. Isso mostra que a idéia é produzir um código bom e limpo e pedir ajuda, se necessário. O processo de revisão é uma cultura, por isso precisamos realmente trabalhar nisso.
Agora, algumas pessoas podem se preocupar que, se fizerem o exposto acima, os desenvolvedores juniores perderão o respeito porque fizeram algo que você não poderia fazer. Mas isso está longe de ser verdade: pedir ajuda mostra humildade. Além disso, existem muitas situações em que você pode brilhar. Finalmente, se esse é o seu medo, você tem problemas de auto-estima. Por fim, talvez eu realmente não saiba: quero dizer que alguns desses desenvolvedores têm algoritmos frescos em suas cabeças porque os estudaram há um mês.
De qualquer forma, de volta aos juniores e comentários. Você deve ver o rosto deles quando descobrirem e me enviar uma resposta. Posso dizer a eles: "OK, deixe-me fazer as alterações e, se você estiver satisfeito com isso, feche o problema".
Eles se sentem impressionados por ter o poder de olhar para o meu trabalho e dizer: "Sim, suas alterações são boas. Fechei a questão".
Eu nunca corrigi o código sozinho porque:
Mas vou sugerir idéias e trechos de código nos meus comentários para ajudar o autor. Observe que, às vezes, minhas análises simplesmente pedem ao autor que eu não entendo o código delas; pode não haver nada errado com o código deles. Eles podem precisar alterar nomes de variáveis, adicionar comentários etc. Assim, nem saberei o que mudar nesse caso; só eles vão.
Se você continuar fazendo análises, mais cedo ou mais tarde terá uma boa idéia do nível de conhecimento de cada desenvolvedor da equipe. Saber isso é realmente útil e você precisa tirar proveito disso e liberá-lo. Aqui está como: Se eu revisar algum código e ver áreas óbvias de aprimoramento e sei que outro desenvolvedor também pode pegá-lo, solicitarei que ele o revise. Algo como "Ei, vejo algumas áreas que podem ser aprimoradas. Você pode revisá-lo com mais detalhes e enviar seus comentários ao autor?" Isso também funciona muito bem, porque agora eu tenho dois outros desenvolvedores trabalhando uns com os outros.
Se estou revisando algum trabalho e percebo algo de que toda a equipe pode se beneficiar, crio um cenário hipotético e explicarei o problema em uma reunião. Começarei explicando o cenário e perguntarei a todos se eles podem encontrar o problema ou vê-lo, envolvê-los. Faça com que todos façam perguntas. Finalmente, apresente uma abordagem melhor. Se alguém tiver uma abordagem melhor, agradeço a eles e reconheço que, diante da equipe, sua abordagem é melhor. Isso mostra que não sou do tipo "personalidade do meu jeito ou da estrada". Além disso, NUNCA abro o trabalho de alguém e começo a apontar os problemas em uma reunião, o autor não o apreciará - independentemente de quão agradável e inofensivo eu ache que estou sendo.
Quando faço revisões, não procuro apenas um bom código limpo, mas também o que o código está fazendo. Se o requisito comercial for: Se um funcionário estiver na empresa há mais de 10 anos, aumente 5%. Caso contrário, 2,5% . A primeira coisa que verifico é se está realmente fazendo isso. Depois, verifico se está fazendo isso de maneira limpa, consistente e com bom desempenho.
Se eu fizer uma revisão, certifique-se de acompanhar ou ninguém levará as críticas a sério.
Eu costumava trabalhar com alguém anos atrás que fazia uma revisão e cc do gerente de desenvolvimento e do gerente de controle de qualidade, mas os dois gerentes eram de uma empresa ou tinham pouca experiência em desenvolvimento. Ele só fez isso para impressioná-los. Ninguém gostou e foi aí que eu disse a mim mesma que nunca cometeria esse erro.
A outra coisa que ele costumava fazer era escolher o estilo de programação e estava convencido de que seu estilo era o melhor ("Meu kung fu é muito melhor que o seu estilo de macaco ..."). Essa foi outra lição para mim: sempre há mais de uma maneira de resolver um problema.
Responda a algumas de suas perguntas numeradas
Não, veja os motivos que afirmei acima.
Sim, tente usar frases e um tom amigável, mas que exija atenção. Seja o mais claro possível. Declare qual é o problema do código, como melhorá-lo. Não basta pedir para mudar isso. Mas forneça razões.
Como eu disse, você pode usar a ferramenta que eu uso ou outra ferramenta. Não use documentos de e-mail ou word, pois eles se perdem e é difícil acompanhar isso.
Principalmente, o que faço é verificar o delta (apenas alterações). Mas você precisa ter a visão geral em mente para garantir que nada seja quebrado e siga a arquitetura.
Pensamentos finais
Pessoalmente, acho que a palavra "revisão de código" é uma má escolha e não sei como ela começou. Eles poderiam ter escolhido uma palavra muito melhor e menos autoritária.
fonte
making sense architecturally, eu quis dizer garantir que o código da camada de acesso a dados esteja dentro da camada de acesso a dados, a validação da interface do usuário esteja na interface do usuário etc. Em outras palavras, garantir que as preocupações não fluam para outras áreas. Existem ferramentas para ajudar a manter a arquitetura; na verdade, o VS faz isso agora fora da caixa agora . Nós usamos isso também.Depende muito de como você entende as revisões de código na sua empresa. Existem empresas em que uma revisão de código é um processo altamente formalizado, que ocorre raramente, mas é um grande negócio. Em outros, a revisão de código é uma parte obrigatória de cada tarefa que é implementada e é algo muito mundano e rápido, com pouco formalismo. Pessoalmente, opto pela última abordagem, mas pode ou não ser sua decisão se você pode usá-la ou não.
Eu escrevi uma postagem no blog intitulada As revisões de código valem o seu tempo? para resumir o processo usado pela minha equipe. Os tópicos, relacionados à sua pergunta, seriam:
Quanto ao ciclo de revisão-correção-verificação-correção, o que você escolher deve depender da maturidade dos desenvolvedores e da gravidade dos problemas detectados. Depois que as equipes fazem das revisões de código um processo diário, você pode esperar que mudanças triviais, como renomear uma classe, sejam simplesmente aplicadas e provavelmente não há necessidade de verificar novamente. Se a equipe ainda não foi vendida em revisões de código ou as pessoas são realmente inexperientes, convém verificar essas coisas independentemente. Por outro lado, se sua revisão detectou um problema complexo de simultaneidade que os desenvolvedores juniores podem não entender completamente, mesmo depois de indicá-los, é melhor verificar a correção e não aprovar a alteração antes de ter certeza de que foi realmente corrigida.
As ferramentas podem ajudá-lo com isso, pois, se você trabalhar com solicitações pull, poderá configurar facilmente o software para não permitir a fusão de uma alteração até que ele tenha a aprovação de um número predeterminado de desenvolvedores. Geralmente, você pode visualizar as alterações em confirmações individuais de uma alteração que permitem analisar facilmente apenas as alterações adicionadas desde a última rodada de comentários.
fonte
Eu voto na segunda opção. Os juniores podem ter uma melhor "curva importante" ao fazer as próprias alterações.
Além disso: não seja o único a revisar o código.
Deixe que alguns dos membros experientes de sua equipe também analisem o código e agendem uma reunião de revisão regular , na qual os revisores apresentam suas conclusões (feitas antes da reunião!) Ao autor. Isso aumentará a motivação de ambos, os juniores e os membros da equipe de experiências.
fonte