O código está revisando as boas práticas?

Quando a empresa em que trabalho contratou novos gerentes, eles nos ofereceram uma visão geral do código de alguém em todas as reuniões. Temos reuniões a cada duas semanas, portanto, cada vez que um dos desenvolvedores mostrava seu código no projetor, outros discutiam.

Eu pensei que isso seria ótimo: cada desenvolvedor teria mais cuidado ao escrever código e poderíamos compartilhar melhor nossa experiência. Mas, de alguma forma, esquecemos disso e a oferta continuou sendo uma oferta.

Quais são os benefícios disso e existem desvantagens?

Revisões de código são uma ótima prática.

É provavelmente a melhor maneira de aprender com os erros e ver como certos problemas são resolvidos por outros. É também uma das melhores maneiras de manter a qualidade em uma base de código.

As revisões de código ocorrem em muitas empresas, embora seja difícil dizer que existe um processo específico que todas elas seguem.

Em uma revisão de código mais formal, um idoso (ou vários idosos) se reunirá com um desenvolvedor para revisar seu código, oferecendo sugestões e ensinando ao mesmo tempo.

Os benefícios adicionais das revisões de código (conforme comentado nesta pergunta) incluem:

• Uma ótima maneira de ensinar e aprender
• Eles são uma das melhores maneiras de melhorar e manter a consistência de uma base de código (estilo e idiomas)
• Eles ajudam a garantir que todos os membros da equipe entendam o estilo e os idiomas usados ​​no projeto e como usá-los
• As revisões de código aceleram o desenvolvimento à medida que detectam erros e projetam falhas mais cedo (portanto, embora possam desacelerar o desenvolvimento inicial, pagam dividendos nos ciclos de desenvolvimento posteriores)
• Há suporte para ferramentas que ajuda a simplificar o processo de revisão de código

As revisões de código são uma ferramenta muito útil para aprender , especialmente quando você tem um novo membro da equipe a bordo. Bem, também é conhecido como processo de revisão por pares :)

Existem diferentes tipos de revisões de código:

• Over-the-ombro - onde um desenvolvedor olha por cima do ombro do autor do código enquanto o último percorre o código.
• Transferência de e-mail - O sistema de gerenciamento de código-fonte envia um e-mail ao revisor automaticamente após o check-in. Extrato do comentário: Tendo falhado em convencer o gerenciamento a alocar tempo para qualquer tipo de revisão formal de código que passei a examinar as alterações de meus colegas de trabalho sempre que retiro novas revisões do controle de origem, usando as ferramentas de histórico / diff incorporadas ao Tortise
• Programação em pares - Dois autores desenvolvem código juntos na mesma estação de trabalho, o que é comum na Extreme Programming.
• Revisão de código assistida por ferramenta - Autores e revisores usam ferramentas especializadas projetadas para revisão de código por pares.

Há apenas um em associated disadvantageque as revisões formais de código exigem um investimento considerável na preparação para o evento de revisão e o tempo de execução.

Mais referências estão listadas abaixo (para leituras mais aprofundadas)

• MSDN - Revisão de Código
• Encontre e corrija vulnerabilidades antes do envio do aplicativo
• Link da Wiki

Essa prática em particular parece ineficiente e provavelmente embaraçosa - quem quer que seus erros sejam apontados para todo um grupo de pessoas. Portanto, se eles não puderem escolher o que deve ser revisado e o código ainda não estiver em produção, isso provavelmente deixará as pessoas desconfortáveis.

Dependendo de quando o código é revisado, pode fazer uma grande diferença se os comentários de revisão de código fazem parte do código ou não. Se o desenvolvedor puder escolher e escolher apenas o código de produção, é improvável que os comentários de revisão sejam implementados. É bom ter reuniões em que os desenvolvedores podem mostrar alguma técnica bacana que aprenderam que outras pessoas estariam interessadas, mas isso não é uma revisão de código. Isso é treinamento.

Fazemos a revisão de código de cada parte do código antes de ser movida para o controle de qualidade. Cada peça. Geralmente envolve apenas o revisor de código e o desenvolvedor. Ele não passa pelo controle de qualidade até que o revisor do código o passe formalmente. Portanto, o desenvolvedor precisa fazer as alterações. Detectamos e corrigimos rapidamente muitos problemas que o controle de qualidade pode não ter encontrado (eles também encontram coisas que não vemos na revisão de código). Além disso, reduz a codificação de cowboys e identifica rapidamente as pessoas que não estão apresentando um bom desempenho, para que possamos resolver seus problemas e treiná-los ou nos livrar deles antes que danifiquem nosso aplicativo. O tempo de revisão do código faz parte de nossa estimativa de tempo ao planejar o trabalho, para que não afete o prazo. E, na verdade, economiza tempo a longo prazo, porque quanto mais cedo um problema é encontrado, mais fácil é corrigir.

Pessoalmente, eu ensinei aos desenvolvedores menos experientes muitas técnicas melhores por meio da revisão de código e aprendi algumas técnicas melhores revisando o código de outras pessoas, bem como seus comentários no meu código. Uma revisão adicional do código garante que alguém entenda o código que ajuda bastante a torná-lo mais sustentável. Às vezes, o código funciona, mas as perguntas da revisão deixam claro que haverá problemas de manutenção porque o código é difícil de entender. É melhor refatorar nesses casos, enquanto tudo ainda está em sua mente do que um ano depois, quando até o autor do código fica coçando a cabeça e se perguntando por que o código faz isso e aquilo.

O problema com esse tipo de revisão de código, um desenvolvedor a cada duas semanas, o progresso será lento. Pode levar meses até que todo mundo se revele sob os holofotes.

Embora as revisões de código possam ser boas, deve haver uma razão por trás delas e por trás do procedimento para fazê-las.

Várias questões teriam que ser decididas:

• Quem escolheria o desenvolvedor e quanto aviso seria dado. Revisões sem aviso prévio são armadilhas.
• Quem selecionaria a parte do código que está sendo revisada: gerenciamento, o desenvolvedor sênior do projeto ou o desenvolvedor que está sendo revisado.
• É o objetivo de ensinar a pessoa cujo código está no projetor a fazer algo melhor, ou é o objetivo de a pessoa cujo código está no projetor ensinar a todos os outros da sala como melhorar seu código.
• Qual porcentagem de código será revisada dessa maneira? Isso fará parte do processo de controle de qualidade?

Se as pessoas que propuseram esse plano ainda não tiverem respostas para essas perguntas, é possível que leiam um artigo sobre como todas as grandes empresas fazem revisões de código, então devemos fazê-las também, sem entender o objetivo por trás delas.

A revisão de código é uma prática recomendada, somente quando a idéia para revisão de código vem da equipe de desenvolvimento. Os desenvolvedores não precisam de projetores e apresentações para revisar o código. Se eles quiserem - eles preferem ir à conferência.

Quando a idéia de revisão de código vem do gerenciamento - pode parecer uma investigação de baixa qualidade de software e pode desmoralizar a equipe de desenvolvimento. Não acho que a equipe de gerenciamento deva estar envolvida no processo de revisão de código. Revisão de código lado a lado com a equipe de gerenciamento - prática muito ruim, matadora e destrutiva.

A revisão de código é uma prática excelente, principalmente se os desenvolvedores fizerem o compartilhamento de conhecimento, e as regras básicas são definidas antecipadamente para que sugestões e críticas sejam CONSTRUTIVAS, e não para usar um desenvolvedor individual para a prática de destino.

Os gerentes que não são desenvolvedores serão recebidos com desconfiança pelos desenvolvedores se decidirem fazer revisões de código. A maioria dos tipos de gerente não deseja entrar em detalhes nos quais os desenvolvedores inerentemente entram em detalhes ao analisar o código. A maioria dos gerentes também não entende por que os desenvolvedores criticam uma abordagem em detrimento de outra.

Se você deseja mostrar o bom trabalho que os desenvolvedores estão fazendo no gerenciamento, a "revisão de código" tem um significado diferente e não deve ser tão detalhada quanto as revisões de código feitas para instruir / melhorar a qualidade do código entre os desenvolvedores. Esse tipo de apresentação pode ser útil para demonstrar o que os desenvolvedores fazem se a apresentação puder ser de nível superior e menos específico do código, focando no que os gerentes entendem (valor, ROI, etc.). Isso pode fazer com que os gerentes entendam que Joe agregou um valor significativo à empresa ao construir X, o que podemos mostrar que economiza uma quantidade de tempo Y ou Z dólares por pedido etc. Acho que valerá a pena o esforço de mostrar o valor individual membros da sua equipe. Lembre-se, no entanto, de que você precisa ter cuidado para não sobrecarregar sua audiência com jargões ou com muitos níveis de detalhes.

Embora eu concorde plenamente que as revisões de código são muito construtivas para o ensino, eu gostaria de destacar que, para mim, é garantir que os padrões de design da equipe sejam seguidos corretamente.

Escrevemos um pequeno trabalho de protótipo e refatoramos partes do código e, embora nos sintamos confortáveis ​​com o produto no final, a legibilidade foi prejudicada - as pessoas não podem olhar para ele e ver claramente o que está acontecendo.

Olhos independentes são sempre benéficos, acho que quando você fica preso em certos modos de pensamento e isso ocorre em todos os níveis de experiência. Você investiu horas no design e no código e, portanto, é difícil lidar com as revisões de código quando há o medo de que seu esforço seja jogado fora. No entanto, no final, espero que você termine com um aplicativo mais limpo, mais enxuto e mais gerenciável, e a experiência está enraizada em você.

Para nossa equipe, fazemos como o @ElYusubov mencionado e usamos uma ferramenta específica para o Code Review - Crisol. As pessoas revisam, comentam e assinam o código. Toda semana, sentamos e revisamos trechos de código interessantes e / ou complexos.

Como estagiário de engenharia de software, achei as revisões de código imensamente úteis.

Na minha equipe, é necessária uma revisão de código para cada confirmação (grandes mudanças acabam sendo formais, pequenas alterações acabam sendo 'rápidas'). Definitivamente, sinto que minhas habilidades de engenharia / design foram aprimoradas por isso, principalmente porque tenho mais probabilidade de retirar o quadro branco do que o terminal imediatamente, pois sei que estou sendo "vigiado". :)

Na verdade, acho que produz um código muito melhor, com a única desvantagem sendo um tempo de desenvolvimento um pouco mais lento (o que, na minha opinião, vale a pena a longo prazo, quando você não precisa corrigir / estender código terrivelmente projetado). Além disso, acho que se você tiver juniores / estagiários na equipe, eles apreciarão a chance de receber um feedback valioso. Eu sei que eu faço!

Da minha experiência, o Code Review é realmente ótimo se você o executar bem. Quando você tem membros e gerentes profissionais / maduros da equipe. Nós, como programadores, somos "solucionadores de soluções". Nosso trabalho não é criar linhas de "texto". É por isso que temos que compartilhar idéias, erros, problemas, experiências. A revisão de código é realmente uma boa prática para conseguir isso.

Infelizmente, parece ótimo, mas é realmente difícil de implementar na maioria das empresas. Sua equipe precisa de muita "autonomia". Convencer seus gerentes ou departamento financeiro de que não criar um novo recurso é lucrativo parece difícil.

Na minha empresa, estamos tentando fazer uma revisão de código. Mas é gasto muito tempo com 'perseguir o coelho' (criar recursos).

Muitas verificações de estilo e tipo de sintaxe básica são capturadas usando ferramentas hoje em dia (FXCop, etc.).

No entanto, as revisões de código são boas, especialmente para os novos membros de uma equipe, coisas complexas ou de alto impacto (por exemplo, algo que será perceptível para pessoas importantes se falhar ou causar impacto nos negócios) e, especialmente, ao terceirizar ou usar contratados de curto prazo (especialmente novamente quando não são falantes nativos, pois erros de tradução / problemas de idioma podem permitir que o software passe em todos os testes, mas não faz o que deveria).

Eu não sou fã de colocar código em um projetor para uma equipe escolher - muito melhor ter uma reunião de revisão de código em que outro membro da equipe (líder da equipe etc) passa por uma lista com o desenvolvedor. Isso afeta menos pessoas - interrompe muito tempo perdido com argumentos de estilo - e é menos embaraçoso para o desenvolvedor. É mais construtivo e mais fácil para o desenvolvedor absorver problemas reais e não ficar cego pelo tipo de comentários "Eu teria feito isso ...".

Também acho que revisões de código não impostas - como colocar código em um compartilhamento ou enviá-lo por e-mail na esperança de que alguém desista da hora do almoço para passar por ele - é uma perda de tempo.

Sentar-se com uma pilha de listagem, um marcador e uma xícara de café na área de café é ótimo para isso.

Esse tipo de apresentação e revelação em grupo seria bom para novas tecnologias ou para obter vários jr. desenvolvedores até a velocidade, mas não acho que seja tão bom quanto uma revisão consistente do novo código. É mais eficiente ter que fazê-lo individualmente.

A revisão de código ajuda a ver "o todo". Desenvolvedores separados tendem a ver apenas seus requisitos / problemas. O CR descobre idéias e soluções de toda a perspectiva. O CR ajuda principalmente a eliminar o desperdício de trabalho desnecessário. Todo o produto é mais barato e de melhor qualidade.