É importante apontar as partes boas do código durante uma revisão de código e as razões pelas quais ele é bom? O feedback positivo pode ser tão útil para o desenvolvedor que está sendo analisado e para os outros que participam da revisão.
Estamos fazendo resenhas usando uma ferramenta on-line para que os desenvolvedores possam abrir resenhas para o código comprometido e outras pessoas possam revisar o código em um determinado período de tempo (por exemplo, uma semana). Outros podem comentar o código ou os comentários de outros revisores.
Deve haver um equilíbrio entre feedback positivo e negativo?
Melhore a qualidade e a moral usando as revisões do código de peer
link
Coisas que todos devem fazer: revisão de código
link
Ambos os artigos afirmam que um dos propósitos da revisão de código é compartilhar conhecimento sobre boas técnicas de desenvolvimento, e não apenas encontrar erros.
Então eu diria que é muito importante. Quem quer ir a uma reunião e só ser criticado?
Quando eu faço revisões de código, eu tento apenas ter um monólogo em execução, então como eu estou entendendo o que estou lendo, haverá um monte de "Ok, eu vejo o que isso faz. Bom, ele se conecta a isso e chama isso, tudo bem .. e essa parte depende de ambos os que estão bem ".
Eu acho que desta forma não é "oo la la isso é tão bom!", pode ser um código chato perfeitamente trivial, mas ouvir alguém realmente analisar e mostrar a compreensão do que você escreveu é uma forma de feedback positivo em e por si só, o feedback sendo "Este código faz sentido", quando eu me deparo com partes que eu não entendo eu peço explicação e quando eu entendo exclamar "Ah, eu entendi".
Eu acho que a simples transferência de compreensão é um elogio a outro engenheiro porque todos nós queremos que nosso código seja compreendido por outros, isso dá uma forma de validação implícita.
Dito isto, se você ver partes do código que são características boas ou positivas (mesmo o código trivial trivial pode ser bom se for a forma mínima dele mesmo) eu definitivamente tento afirmar essas características, novamente eu não as atribuo como "Uau ótimo!" tanto quanto "eu vejo isso é uma implementação mínima" ou "Ok, este algoritmo complexo tem muitos comentários", focar os atributos do código não é tanto bondade inerente ou maldade.
Sempre que você atribuir "bondade" ou "maldade" ao código em uma revisão de código para evitar que o engenheiro se sinta desprezado ou preso a um pedestal, não diga que algo é bom ou ruim, mas fale sobre a causa e o efeito do código deles.
"Ok, esta parte faz sentido, ah há um número mágico aqui, o significado desse valor pode não ser bem entendido pelo próximo engenheiro para tocar isso"
"Eu vejo que você tem um contêiner de DI aqui ok, então você terá um baixo acoplamento com esse repositório"
"Ah, há um dicionário estático aqui, se vários segmentos tocarem no dicionário, poderemos encontrar algumas condições de corrida"
Observe que não estou dizendo que algo seja bom ou ruim, mas se o engenheiro deve alterá-lo ou não, isso será entendido pelo engenheiro cujo código está sendo revisado. Obviamente, você tem que terminar a revisão do código com um yay ou nay, mas acumular essas declarações ao longo do curso suavizará o nay como explicação já foi feita na forma de declarações de causa e efeito quando você diz "eu gostaria esses números mágicos corrigidos antes de verificar isso em ".
Se eu visse algo em uma revisão de código que eu realmente gostasse e estivesse acima e além do código "bom o suficiente", daria um feedback positivo.
Em geral, acho que se alguém escreve um código que realmente faz você dizer "Uau, isso é muito legal!" então sim, o feedback positivo é importante - isso torna conhecido para o autor que o que eles fizeram foi apreciado por outros, e eles deveriam tentar fazer isso de novo. Tem que ser mais do que seguir apenas diretrizes e práticas padrão. Dar louvores porque alguém recuou bem ou acrescentou comentários padronizados poderia definir um nível baixo.
Esta não é uma questão de programação, pois é uma questão de gerenciamento geral e interações humanas. O feedback positivo nas revisões de código é exatamente tão importante quanto o feedback positivo em qualquer tipo de revisão.
Se isso é necessário ou não (e até que ponto isso é necessário) é uma função da disposição e composição emocional da pessoa com quem você está falando. Algumas pessoas respondem à correção de maneira muito mais eficaz quando combinadas com elogios. Outros vêem elogios como insinceros quando entregues com correção.
A fórmula geral é às vezes chamada de "Feedback Sandwich": coisas boas primeiro, coisas ruins depois, coisas boas por último. A ideia é manter o tom geral positivo e, ao mesmo tempo, garantir que o feedback negativo seja recebido. Isso pode ajudar a prevenir o estresse ao antecipar uma revisão e ajudar a prevenir a auto-absorção depois. Ambos são muito importantes no que diz respeito à produtividade e qualidade. Isso não é apenas uma besteira emotiva; É o comportamento humano 101.
Novamente, você precisa conhecer a pessoa com quem está trabalhando e entender a que ela responde. Lidar com as pessoas é sobre o que é gestão e bons gerentes sabem como fazer as pessoas responderem.
Eu acho que o feedback positivo é muito importante e é principalmente a partir de uma dinâmica pessoal e realpolitik. Todos nós nos sentamos e escrevemos código por horas, dias, semanas, meses e a maioria de nós se orgulha do que fazemos. As revisões de código são uma chance de mostrar isso.
Se você for a uma revisão de código e o melhor resultado que pode esperar é "nenhum comentário" (ou seja, não há saldo de feedback positivo), a reunião pode ser facilmente intitulada "Descubra como as pessoas pensam mal Sugue ". Consequentemente, os desenvolvedores começarão a ficar incomodados ou até com críticas de código, e isso é claramente um prejuízo para a equipe. Os desenvolvedores "esquecerão" de revisar seu código ou desenvolverão o desamparo aprendido e simplesmente perguntarão a seus críticos constantes o que fazer a respeito de cada pequena coisa para evitar serem criticados nessas reuniões.
É bom dizer que, teoricamente, é mais lógico consertar o mal e pedir a todos que deixem as emoções na porta, mas são precisamente atitudes como aquela que é responsável pelos desenvolvedores do rep como sendo interpessoalmente. Tom surdo. Teorias à parte, nós humanos e humanos gostamos de dar um tapinha nas costas de vez em quando, até mesmo um nominal. Essa coisa é importante.
É mais importante se você fizer análises lado a lado ou de equipe. Em uma revisão por escrito, nenhuma notícia é uma boa notícia. O objetivo é colocar o código em produção. Quando é o seu código, você deve se sentir bem consigo mesmo.
A revisão de código deve ser usada como uma fonte de informações para ajudar na orientação e gerenciamento da equipe. Há muitas oportunidades para dar feedback positivo sem sobrecarregar o banco de dados de análise de código. Exemplos podem ser retirados para compartilhar com os outros.
Há muito mais para revisar o desenvolvedor além do código. O tempo de revisão do código de invasão pode ser contraproducente para que um aplicativo seja lançado. Defina um tempo específico para ajudar o desenvolvedor fora das revisões de código, mas isso não significa que você deve excluir o feedback da revisão de código.
A única maneira que eu posso pensar em fornecer feedback positivo sobre o código pode ser contra-atacar se você não tomar cuidado para evitar o "elogio backhand". A maioria das pessoas está familiarizada com isso ... é significada por frases como "Ótimo trabalho, mas ..."
Se todos comparecerem à reunião com a atitude de que esta não é uma revisão pessoal do programador, mas um esforço para melhorar a prática de codificação para a qualidade de todo o sistema, então todo o feedback é um "bom" feedback. O feedback que destaca formas de melhorar a prática de codificação torna-se tão importante quanto o feedback, destacando um novo método útil para lidar com um problema.
No mínimo, se alguém não vai a esse tamanho, deve ser enfatizado que o esforço para fazer um ciclo de "feedback bom, feedback ruim, feedback bom, feedback ruim" dentro do processo de revisão só vai acontecer através do mesmo sentimento de elogio backhand. Não tente forçar um bom feedback, tente reforçar o bom esforço e escorar buracos no conhecimento.
Frases das quais aprendi ao longo dos anos:
O fluxo de trabalho que mais gostei com revisões de código foi o seguinte:
Normalmente, o que aconteceria é que novos desenvolvedores receberiam muito mais comentários "correcionais" à medida que se familiarizassem com a base de código.
Os benefícios dessa abordagem são:
Eu não posso concordar com isso. Qual é a diferença entre o Good Development Techniques e os chamados Ninja Coders, que podem escrever códigos impressionantes, mas inexplicáveis, a meros mortais? O Desenvolvimento de Software é agora (IMO) uma disciplina do Menor Denominador Comum em que o talento e astúcia são evitados em favor da manutenção e da facilidade de entendimento. É muito arriscado.
Eu não consigo pensar em uma vez que vi código em uma resenha que me faria pensar 'Oh, isso é legal'. Eu só posso supor que se eu encontrasse um código como este, ele cairia no campo Cool-Yet-Inaceitável.
Você também teria problemas com pessoas que não recebem feedback positivo, talvez tentando muito e fazendo uma bagunça eventual. "Confie em mim, funciona!".
Revisões de código estão disponíveis para distribuir a responsabilidade pela qualidade do código entre a equipe, ou seja, um desenvolvedor individual não pode ser responsabilizado se um problema sério surgir posteriormente. Use-o para encontrar problemas, use-o para obter explicações do desenvolvedor original de coisas estranhas, caso você acabe tendo que mantê-lo. Pessoalmente, estou mais interessado em receber feedback negativo. Os clientes não se importam com o frescor do seu código, apenas que ele faz o que eles querem.
Deixe o backslapping no pub.
Isso importou para mim. Eu não quero comentários de fluff ou positividade por causa da positividade. Se todo o código que eu escrevi é péssimo, você me diz por que e vamos corrigi-lo e aprender. Mas se eu fizer algo certo, é bom ouvir uma vez e por algum tempo. Eu não preciso de reforço positivo para tudo o que fiz que era "correto", mas mesmo que seja um "vamos melhorar X, Y e Z, mas o resto parece bom", importa.
Não é tão importante quanto um feedback honesto. Eu trabalho para uma grande corporação financeira, e nossos clientes não se importam se o programador está se esforçando ou se é um bom rapaz, ou geralmente escreve um bom código! Eles exigem software que funcione.
Eu acho que é importante ser completamente objetivo. Tentar aumentar o moral fazendo comentários positivos é uma perda de tempo para minha mente.
Isso pode significar que as revisões de código são indevidamente críticas - mas não é esse o ponto. Nós também devemos ser críticos de nós mesmos. Acho que a suposição de que o código que escrevi é provavelmente um lixo completo e que definitivamente poderia ser aprimorado me leva a melhorar meu código e meu nível de habilidade.
Se você não receber comentários, poderá considerar que fez um bom trabalho.
O mantra é simples: se alguém quiser um código de qualidade (o que é menos na realidade), então métodos adequados de revisão devem ser praticados. Dito isto, o feedback positivo ajuda o desenvolvedor / programador a pensar e apresentar ideias / soluções / correções. Não seja muito severo, mas seja firme no ponto. Os gerentes de perguntas e respostas devem estar cientes de boas metodologias e práticas para que possam orientar a equipe (ou um membro) na direção certa. Isso resulta em qualidade. Período.
Quando o código é para uma competição ou submetido a uma entrevista de emprego (em outras palavras, código escrito e não pode ser reescrito), os comentários positivos são obrigatórios. Na verdade, você deve garantir que haja feedback positivo (quando possível!) E negativo. Dessa forma, o codificador sabe onde estão seus pontos strongs e fracos e pode compensar.
No entanto, você parece estar falando em um ambiente de trabalho, onde o código pode ser reescrito. Nesse caso, você está tentando fazer com que os bugs saiam do seu sistema. Então, nessa situação, apenas bugs negativos valem a pena.
Se você se sentir desconfortável com isso, faça uma reunião semanal de revisão de código, onde todos possam discutir tanto o código bom quanto o código ruim.
EDIT: Embora eu vou dizer que, se algo impressiona o suficiente, não há nada que você parar de expressar seu louvor em pessoa. O rastreador, no entanto, parece ser apenas para revisão de código de produção.Tags code-reviews