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:
- Preciso de ajuda para que eles não entrem no modo defensivo.
- 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:
- O autor não aprenderá com isso.
- É como eu dizendo: "Afaste-se, deixe-me mostrar como isso é feito. Meu código é melhor que o seu".
- 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.