Classificar indivíduos em uma revisão é contrário aos sistemas mais bem-sucedidos com os quais trabalhei, talvez todos. Mas o objetivo que tenho tentado alcançar há mais de 20 anos é menos bugs e maior produtividade por hora de engenheiro. Se a classificação de indivíduos é uma meta, suponho que as revisões possam ser usadas. Nunca vi uma situação em que isso fosse necessário, como trabalhador ou líder.
Alguns estudos objetivos (Fagan, etc.) e muita sabedoria popular sugerem que os relacionamentos entre pares facilitam as revisões de código destinadas a reduzir bugs e aumentar a produtividade. Os gerentes de trabalho podem participar como trabalhadores, mas não como gerentes. Os pontos de discussão são observados, as mudanças para satisfazer os revisores geralmente são boas, mas não são necessárias. Daí a relação entre pares.
Quaisquer ferramentas automatizadas que possam ser aceitas sem análises ou julgamentos adicionais são úteis em C, C ++, Java. Compilação regular. Compiladores são realmente bons em encontrar erros de compilador. A documentação de desvios nas verificações automatizadas soa como uma acusação sutil das verificações automatizadas. Diretivas de código (como Java faz) que permitem desvios são bastante perigosos, IMHO. Ótimo para depuração, para permitir que você entenda o assunto rapidamente. Não é tão bom encontrar em um bloco de código com menos de 50.000 linhas de comentários e mal documentado pelo qual você se tornou responsável.
Algumas regras são estúpidas, mas fáceis de aplicar; padrões para cada instrução switch, mesmo quando inacessíveis, por exemplo. Então é apenas uma caixa de seleção e você não precisa gastar tempo e dinheiro testando valores que não correspondem a nada. Se você tiver regras , terá insensatez , elas são indissociáveis . O benefício de qualquer regra deve valer a tolice que custa, e esse relacionamento deve ser verificado em intervalos regulares.
Por outro lado, "Funciona" não é virtude antes da revisão, nem defesa na revisão. Se o desenvolvimento seguiu o modelo em cascata , você gostaria de fazer a revisão quando a codificação estiver 85% concluída, antes que erros complicados sejam encontrados e solucionados, porque a revisão é uma maneira mais barata de encontrá-los. Como a vida real não é o modelo em cascata, quando revisar é algo de uma arte e equivale a uma norma social. As pessoas que realmente lerão seu código e procurarão problemas são ouro sólido. A administração que suporta isso de maneira contínua é uma pérola acima do preço. As revisões devem ser como check-ins, antecipadas e frequentes .
Eu achei essas coisas benéficas:
1) Sem guerras de estilo . Para onde vão os chavetas abertas, deve estar sujeito apenas a uma verificação de consistência em um determinado arquivo. Tudo o mesmo. Tudo bem então. O mesmo vale para a profundidade de recuo ** se ** as larguras de tabulação . A maioria das organizações descobre que precisa de um padrão comum para tabulação, usado como um espaço grande.
2) `Ragged
looking
texto que não
line up is hard to read
para o conteúdo.`
Aliás, a K&R identificou cinco (CINCO) espaços, portanto, os apelos à autoridade são inúteis. Apenas seja consistente.
3) Uma cópia numerada de linha, inalterável e disponível ao público do arquivo a ser revisado deve ser apontada por 72 horas ou mais antes da revisão.
4) Nenhum projeto on-the-fly. Se houver um problema ou um problema, anote sua localização e siga em frente.
5) O teste que percorre todos os caminhos no ambiente de desenvolvimento é uma idéia muito, muito, muito, muito boa. Testes que exigem dados externos maciços, recursos de hardware, uso do site do cliente etc. etc são testes que custam uma fortuna e não serão completos.
6) Um formato de arquivo não ASCII é aceitável se ferramentas de criação, exibição, edição etc. existirem ou forem criadas no início do desenvolvimento. Esse é um viés pessoal meu, mas em um mundo em que o sistema operacional dominante não pode sair do seu caminho com menos de 1 gigabyte de RAM, não consigo entender por que arquivos com menos de, digamos, 10 megabytes devem ser qualquer coisa diferente de ASCII ou algum outro formato comercialmente suportado. Existem padrões para gráficos, som, filmes, executável e ferramentas que os acompanham. Não há desculpa para um arquivo que contém uma representação binária de algum número de objetos.
Para manutenção, refatoração ou desenvolvimento de código liberado, um grupo de colegas de trabalho que eu havia usado para revisar por outra pessoa, sentado em uma tela e olhando para um diferencial do antigo e do novo , como uma porta de entrada para o check-in da filial. Eu gostei, era barato, rápido, relativamente fácil de fazer. As orientações para pessoas que não leram o código com antecedência podem ser educativas para todos, mas raramente aprimoram o código do desenvolvedor.
Se você está geograficamente distribuído, olhar para as diferenças na tela enquanto conversa com alguém olhando para o mesmo seria relativamente fácil. Isso abrange duas pessoas olhando para mudanças. Para um grupo maior que leu o código em questão, vários sites não são muito mais difíceis do que todos em uma sala. Várias salas ligadas por telas de computador compartilhadas e caixas de proteção funcionam muito bem, IMHO. Quanto mais sites, mais gerenciamento de reuniões é necessário. Um gerente como facilitador pode ganhar seu sustento aqui. Lembre-se de continuar pesquisando os sites em que você não está.
Em um ponto, a mesma organização tinha testes de unidade automatizados que foram usados como testes de regressão. Isso foi muito legal. É claro que mudamos de plataforma e o teste automatizado foi deixado para trás. A revisão é melhor, como observa o Manifesto Ágil , os relacionamentos são mais importantes que processos ou ferramentas . Porém, após a revisão, os testes de unidade / testes de regressão automatizados são a próxima ajuda mais importante na criação de um bom software.
Se você puder basear os testes nos requisitos , bem, como a senhora diz em "Quando Harry conheceu Sally" , terei o que ela está tendo!
Todas as revisões precisam ter um estacionamento para capturar requisitos e problemas de design no nível acima da codificação. Uma vez que algo é reconhecido como pertencente ao estacionamento, a discussão deve parar na revisão.
Às vezes, acho que a revisão de código deve ser como revisões esquemáticas no design de hardware - completamente público, completo, tutorial, o fim de um processo, um gateway após o qual é construído e testado. Porém, as revisões esquemáticas são pesadas porque a alteração de objetos físicos é cara. As revisões de arquitetura, interface e documentação de software provavelmente devem ser pesadas. O código é mais fluido. A revisão de código deve ser mais leve.
De várias maneiras, acho que a tecnologia é tanto sobre cultura e expectativa quanto sobre uma ferramenta específica. Pense em todas as improvisações da " Swiss Family Robinson " / Flintstones / McGyver que encantam o coração e desafiam a mente. Queremos que nossas coisas funcionem . Não existe um único caminho para isso, assim como não havia "inteligência" que de alguma forma pudesse ser abstraída e automatizada pelos programas de IA da década de 1960 .