Qual a importância do feedback positivo nas revisões de código?

É 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 igualmente útil para o desenvolvedor que está sendo revisado e para os outros que participam da revisão.

Estamos fazendo análises usando uma ferramenta on-line, para que os desenvolvedores possam abrir análises para seu código confirmado e outros possam revisar seu código dentro de um determinado período de tempo (por exemplo, 1 semana). Outros podem comentar o código ou os comentários de outros revisores.

Deveria haver um equilíbrio entre feedback positivo e negativo?

Melhorar a qualidade e o moral usando as revisões de código por pares
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

Coisas que todos deveriam fazer: Revisão de código
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

Ambos os artigos afirmam que um dos objetivos da revisão de código é compartilhar conhecimento sobre boas técnicas de desenvolvimento, não apenas encontrar erros.

Então, eu diria que é muito importante. Quem quer ir a uma reunião e apenas ser criticado?

Quando faço revisões de código, costumo ter apenas um monólogo em execução; portanto, como estou entendendo o que estou lendo, haverá muito "Ok, entendo o que isso faz. Bom, isso se conecta a isso e chama isso, tudo bem ... e essa peça depende dos dois. "

Eu acho que dessa maneira não é "oo la la, isso é ótimo!", Poderia ser um código chato perfeitamente trivial, mas ouvir alguém realmente analisar e mostrar compreensão do que você escreveu é uma forma de feedback positivo por si só, sendo o feedback "Este código faz sentido", quando encontro partes que não entendo, peço explicações e quando entendo, exclamo "Ah, entendi".

Eu acho que a simples transferência de compreensão é um elogio para outro engenheiro, porque todos queremos que nosso código seja entendido por outros, isso fornece uma forma de validação implícita.

Dito isso, se você ver partes do código com características boas ou positivas (mesmo o código trivial chato pode ser bom se for a forma mínima em si) eu definitivamente tendem a indicar essas características, novamente não as atribuo como "Uau ótimo!" tanto quanto "vejo que essa é uma implementação mínima" ou "ok, esse algoritmo complexo tem muitos comentários", concentram-se nos atributos do código, não tanto na bondade ou na maldade inerentes.

Sempre que você atribuir "bondade" ou "maldade" ao código em uma revisão de código para evitar que o engenheiro se sinta menosprezado ou mantido em um pedestal, não diga que algo é bom ou ruim, mas fale sobre a causa e o efeito de o código deles.

"Ok, essa parte faz sentido, ah há um número mágico aqui, o significado desse valor pode não ser bem compreendido pelo próximo engenheiro para tocar nisso"

"Vejo que você tem um contêiner de DI aqui ok, então você terá um acoplamento frouxo com esse repositório"

"Ah, existe um dicionário estático aqui, se vários threads estiverem tocando nesse dicionário, podemos encontrar algumas condições de corrida"

Observe que não estou dizendo que algo seja bom ou ruim, mas se o engenheiro deve mudar ou não será entendido pelo engenheiro cujo código está sendo revisado. Obviamente, você deve encerrar a revisão do código com um yay ou não, mas acumular essas instruções ao longo do processo suavizará as negativas, já que a explicação já foi feita na forma de declarações de causa e efeito quando você diz a eles "Eu gostaria esses números mágicos corrigidos antes de fazer check-in ".

Se eu vi algo em uma revisão de código que realmente gostei e estava acima e além do código "bom o suficiente", daria um feedback positivo.

Em geral, acho que se alguém escrever um código de peça que realmente faça você dizer "Uau, isso é muito legal!" então sim, o feedback positivo é importante - torna conhecido ao autor que o que eles fizeram foi apreciado por outros, e eles deveriam tentar fazer isso novamente. Tem que ser mais do que apenas seguir diretrizes e práticas padrão. Elogiar porque alguém recuou muito bem ou acrescentou comentários adicionais poderia definir um nível bastante baixo.

Isso não é tanto uma questão de programação, é uma questão geral de gerenciamento 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 é 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 combinada 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 idéia é 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 evitar a ninhada auto-absorvida posteriormente. Ambos são muito importantes em relação à produtividade e qualidade. Isso não é apenas besteira emocional sensível; É o comportamento humano 101.

Novamente, você precisa conhecer a pessoa com quem está trabalhando e entender o que ela responde. Lidar com as pessoas é o objetivo da administração, e bons gerentes sabem como fazer as pessoas responderem.

Acho que o feedback positivo é muito importante e é principalmente de uma dinâmica pessoal e política real. Todos sentamos e escrevemos código por horas, dias, semanas, meses e a maioria de nós se orgulha do que faz. 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 você pode esperar for "sem comentários" (ou seja, não há equilíbrio de feedback positivo), a reunião poderia facilmente ser intitulada na perspectiva "Descubra como as pessoas pensam que você é péssima". Conseqüentemente, os desenvolvedores começarão a se incomodar com as revisões de código ou mesmo com pavor, e isso é claramente um prejuízo para a equipe. Os desenvolvedores "esquecem" de revisar seu código ou desenvolvem desamparo aprendido e simplesmente perguntam a seus críticos constantes o que fazer com relação a cada pequena coisa, para evitar ser criticado nessas reuniões.

É bom dizer que, teoricamente, é mais lógico corrigir os problemas e pedir a todos que deixem emoções à porta, mas são precisamente atitudes como aquela que é responsável pelos desenvolvedores de representantes como sendo interpessoais. Teorias à parte, somos humanos e os seres humanos gostam de dar um tapinha nas costas de vez em quando, mesmo que seja nominal. Isso importa.

É mais importante se você estiver fazendo revisões lado a lado ou em equipe. Em uma revisão escrita, nenhuma notícia é boa. 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 fonte de informações para ajudar na orientação e gerenciamento da equipe. Há muitas oportunidades para dar um feedback positivo sem sobrecarregar o banco de dados de revisão de código. Exemplos podem ser retirados para compartilhar com outras pessoas.

Há muito mais para revisar o desenvolvedor que não seja o código. O tempo de revisão do código de seqüestro pode ser contraproducente para obter um aplicativo fora da porta. Defina um horário específico para ajudar o desenvolvedor fora das revisões de código, mas isso não significa que você deva excluir os comentários da revisão de código.

A única maneira de pensar em onde o feedback positivo sobre o código pode sair pela culatra é se você não tomar cuidado para evitar o "elogio". A maioria das pessoas está familiarizada com isso ... é representada por frases como "Ótimo trabalho, mas ..."

Se todos vierem à reunião com a atitude de que essa 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, todo feedback será "bom". O feedback que destaca maneiras de melhorar a prática de codificação se torna tão importante quanto o feedback, destacando um novo método útil para lidar com um problema.

No mínimo, se não formos tão longe, deve-se enfatizar que se esforçar para fazer um ciclo de "bom feedback, feedback ruim, feedback bom, feedback ruim" dentro do processo de revisão só vai se deparar com o mesmo sentimento elogio backhand. Não tente forçar um bom feedback, tente reforçar um bom esforço e crie buracos no conhecimento.

Frases que aprendi ao longo dos anos:

• "Essa é uma abordagem interessante. O que acontece se precisarmos acomodar [algum outro caso de uso]?"
• "Boa tentativa! Você sabia que já temos um método para fazer isso? Talvez devêssemos fazer alguns testes comparativos para ver qual abordagem é mais eficiente."

O fluxo de trabalho que eu mais gostei com as revisões de código foi este:

1. O Dev envia um patch na lista de discussão / ferramenta online.
2. Todo mundo que precisa se preocupar olha para o patch, sugere melhorias.
3. Dev volta ao # 1
4. Se não houver necessidade de melhorias, as pessoas dizem "Bom trabalho, por favor, se comprometa". <- FEEDBACK POSITIVO. Todo o código aceito é bom. Quanto menos pessoas tiverem que pedir para você mudar as coisas, melhor você estará.
5. Dev confirma, passa para o próximo item.

Normalmente, o que aconteceria é que os novos desenvolvedores receberiam muito mais feedback 'correcional' à medida que se familiarizassem com a base de código.

Os benefícios dessa abordagem são:

1. Todo mundo sabe o que todo mundo está fazendo. Não há monopólio do conhecimento ou comprometimento de mistérios.
2. Todo mundo aprende com o feedback dos outros. Isso é importante. Se o feedback ocorrer apenas entre duas pessoas em uma conversa frente a frente durante o pareamento, alguém do outro lado da sala não se beneficiará da mesma maneira que faria se acontecesse na lista de discussão.
3. Outros desenvolvedores geralmente podem detectar alguns erros antes de estarem no controle de versão.

Não posso concordar com isso. Qual é a diferença entre Boas Técnicas de Desenvolvimento e os chamados Ninja Coders, que podem escrever códigos incríveis, mas inexplicáveis ​​para meros mortais? O Desenvolvimento de Software é agora (IMO) a disciplina de Denominador Comum Mais Baixo, onde talento e astúcia são evitados em favor da manutenção e facilidade de entendimento. É muito arriscado.

Não consigo pensar em uma época em que eu já vi código em uma revisão que me faria dizer 'Oh, isso é legal'. Só posso supor que, se eu encontrasse um código como esse, ele entraria no campo Legal-Ainda-Inaceitável.

Você também teria problemas com pessoas que não recebem feedback positivo, talvez se esforçando demais e fazendo uma eventual bagunça "Confie em mim, funciona!".

As revisões de código existem para espalhar 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 mais tarde. Use-o para encontrar problemas, use-o para obter explicações do desenvolvedor original de coisas estranhas, caso você precise mantê-lo. Pessoalmente, estou mais interessado em receber feedback negativo. Os clientes não se preocupam com a frescura do seu código, apenas com o que desejam.

Deixe o verso para o pub.

Isso tem importância para mim. Não quero comentários fofos ou positividade por uma questão de positividade. Se todo o código que escrevi for ruim, você me diz o porquê e vamos corrigi-lo e aprender. Mas se eu fizer algo certo, é bom ouvi-lo de vez em quando. Não preciso de reforço positivo porque tudo que fiz foi "correto", mas mesmo que seja um "vamos melhorar X, Y e Z, mas o resto parece bom", é importante.

Não é tão importante quanto o feedback honesto. Eu trabalho para uma grande empresa financeira, e nossos clientes não se importam se o programador está se esforçando ou é um cara legal, 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. Também devemos criticar a nós mesmos. Acho que a suposição de que o código que eu escrevi provavelmente é lixo completo e definitivamente poderia ser melhorado 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 deseja um código de qualidade (que na realidade é menos), deve-se praticar métodos de revisão adequados. Dito isto, o feedback positivo ajuda um desenvolvedor / programador a pensar e ter idéias / soluções / correções. Não seja muito duro, mas seja firme no assunto. Os gerentes de perguntas e respostas devem estar cientes das boas metodologias e práticas para que possam guiar a equipe (ou um membro) na direção certa. Isso resulta em qualidade. Período.

Quando o código é para uma competição ou enviado para uma entrevista de emprego (em outras palavras, código escrito e não pode ser reescrito), comentários positivos são obrigatórios. De fato, você deve garantir que haja feedback positivo (sempre que possível!) E negativo. Dessa forma, o codificador sabe onde estão seus pontos fortes 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 eliminar bugs do seu sistema. Portanto, nessa situação, apenas os bugs negativos têm valor.

Se você se sentir desconfortável com isso, faça uma reunião semanal de revisão de código, na qual todos possam discutir o código bom e o ruim.

EDIT: Embora eu diga que, se algo o impressionar o suficiente, não há nada que o impeça de expressar seus elogios pessoalmente. O rastreador, no entanto, parece ser apenas para revisão do código de produção.