Como dar feedback após o processo de revisão de código


10

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:

  1. Devo corrigir o código sozinho?

  2. 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?


Respostas:


14

Resposta curta

Devo corrigir o código sozinho?

Não.

Devo dar a eles feedback sobre o processo de revisão e deixá-los fazer as correções de acordo com minhas instruções?

Sim. De acordo com suas sugestões , não instruções . As instruções parecem muito autoritárias.

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).

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

Analisei seu código e há alguns itens que você precisa alterar.

Em vez disso, digo o seguinte:

Melhor escolha de redação

Eu olhei para o seu código e preciso de ajuda. Você pode revisar os itens que enviei e ver se consegue esclarecer algumas das minhas perguntas?

Isso faz o autor pensar:

  1. Preciso de ajuda para que eles não entrem no modo defensivo.
  2. Parece que eles são o revisor, não eu. Tecnicamente falando, já que estou pedindo a eles para dar uma outra olhada e mudar algumas coisas, eles meio que são como o revisor.

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:

Você pode rever algum código para mim porque não consigo descobrir.

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:

  1. O autor não aprenderá com isso.
  2. É como eu dizendo: "Afaste-se, deixe-me mostrar como isso é feito. Meu código é melhor que o seu".
  3. Por que eu deveria? Isso é mais trabalho para mim.

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

1- devo corrigir o código sozinho?

Não, veja os motivos que afirmei acima.

2- devo dar feedback sobre o processo de revisão e permitir que eles corrijam de acordo com minhas instruções?

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 faço para enviar esse feedback, preencho determinado documento de modelo e o envio a eles, ou existe algum software que me ajudará a marcar problemas com problemas nos arquivos de código, onde eles poderão verificar mais tarde? (Estou usando o Visual Studio).

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.

Depois que eu revisei o código e as correções foram concluídas, algum tempo 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?

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.


Isso funcionaria apenas para pequenas coisas, como nomes de variáveis. No entanto, se a arquitetura estiver errada, não há ferramenta que possa ajudar. Você só precisa jogar a coisa toda fora e reescrevê-la.
T3chb0t

@ t3chb0t Por que pequenas coisas? Por isso 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.
CodingYoshi

No que diz respeito às ferramentas, acho que uma ferramenta perfeitamente válida a ser utilizada é qualquer forma de software de acompanhamento de bilhetes / trabalho que você provavelmente já usa para rastrear o que precisa ser feito. Por exemplo, se você estiver usando o Github, poderá ter todas as alterações associadas a um problema e a revisão será feita nesse segmento de discussão. Jira e Trac são outras duas ferramentas desse tipo. Isso mantém um local centralizado para todas as informações relacionadas ao trabalho e fica claramente visível antes do fechamento do ticket.
Kat

@ Kat Não tenho certeza se uma ferramenta de emissão de bilhetes é a ferramenta certa a ser usada aqui. As ferramentas de revisão de código mostram a diferença entre alterações e os problemas são problemas diferentes dos problemas em um sistema de emissão de bilhetes; eles significam coisas diferentes. Mas eu posso estar errado.
CodingYoshi

3

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:

  1. Deixe os desenvolvedores corrigirem o código. Isso permitirá que eles entendam melhor seus comentários (ou percebam que não os entendem e perguntam completamente), e executar uma tarefa é uma maneira melhor de aprender do que apenas ler sobre ele.
  2. Software para revisões de código é o caminho a percorrer. Existem muitas opções disponíveis, de código aberto e proprietárias. A maior parte funciona com o git. Minha equipe usa o BitBucket (anteriormente conhecido como Stash), também existem o GitLab e o GitHub, o Gerrit (do qual eu pessoalmente não sou fã) e muitos outros. A maioria desses aplicativos é baseada na Web, portanto, não importa qual IDE você usa, mas também existem plugins para muitos IDEs, por isso tenho certeza de que também existem alguns para o Visual Studio. Um software como esse permite revisar o código antes que ele seja mesclado na ramificação principal (geralmente por meio de solicitações de recebimento) e mostra as partes modificadas e algumas linhas de contexto em torno de cada alteração. Isso torna a revisão do código fluente e sem complicações.

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.


1

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.


4
Ótimo ponto. Além disso, os juniores devem "revisar" o código do OP e o código um do outro também.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.