Como reviso meu próprio código? [fechadas]

Estou trabalhando em um projeto solo e tenho que manter meu próprio código. Normalmente, a revisão do código não é feita pelo autor do código; portanto, o revisor pode olhar o código com novos olhos - no entanto, eu não tenho esse luxo. Quais práticas posso empregar para revisar com mais eficiência meu próprio código?

Primeiro de tudo, use as ferramentas para verificar o máximo que puder. Os testes (com uma cobertura razoável de código) darão a você alguma confiança na correção do código. As ferramentas de análise estática podem capturar muitas das melhores práticas. Sempre haverá problemas nos quais você precisa de olhos humanos para determinar e nunca fará um trabalho tão bom revisando suas próprias coisas quanto outra pessoa; há algumas coisas que você pode fazer para ajudar, no entanto

• verificar se os testes existem e são aprovados (possivelmente tenha uma cobertura de teste de destino, embora você possa precisar quebrá-lo em certos casos, mas seja capaz de justificar o motivo)
• verifique as passagens de análise estática (também haverá falsos negativos aqui, mas tudo bem, desde que você possa justificar por que, então é bom suprimi-los)
• mantenha uma lista de verificação de outras coisas para verificar na revisão (de preferência, adicione-a como novas regras de análise estática, se possível); verifique se tudo o que o SA não pode verificar, por exemplo, se os comentários ainda são válidos, se as coisas são nomeadas adequadamente é claro, um dos 2 problemas difíceis conhecidos pela ciência da computação)
• se uma falha for identificada, verifique se a causa é sistêmica e veja por que não foi encontrada em testes ou análises anteriores

Obviamente, isso é útil quando você está revisando o código de outras pessoas

Dê uma olhada no site do Code Review Stack Exchange. É para compartilhar código de projetos nos quais você está trabalhando para revisão por pares :

Revisão de código O Stack Exchange é um site de perguntas e respostas para buscar a revisão por pares do seu código. Estamos trabalhando juntos para melhorar as habilidades dos programadores em todo o mundo, adotando o código de trabalho e melhorando-o.

Se você está procurando feedback sobre um código de trabalho específico do seu projeto nas seguintes áreas…

• Práticas recomendadas e uso de padrões de design
• Problemas de segurança
• atuação
• Correção em casos imprevistos

Você também pode usar ferramentas de análise estática de código para detectar certos tipos de problemas, mas eles produzirão alarmes falsos em alguns casos e não podem sugerir como melhorar o design.

Eu desenvolvi várias pessoas totalmente diferentes na minha cabeça. Um deles nem é um programador! Estamos conversando, discutindo as últimas notícias e revisando o código um do outro.

Eu recomendo fortemente minha abordagem.

ps Ele não está brincando.

Concordo com a opinião da jk-s de que a revisão individual não é tão eficiente quanto a revisão individual. no entanto, você pode tentar fazer o melhor possível:

revisão de curto prazo (logo após a produção do código)

Estou usando o git como um repositório local. Sempre que terminei um recurso ou corrigi um erro, transfiro as alterações para o repositório.

Antes de fazer o check-in, comparo o que alterei no meu código e repenso:

• os nomes de variável / método / classe ainda refletem para que são usados?

revisão a longo prazo (6 meses após a produção do código)

Eu me pergunto:

• posso descrever em um sentido o que uma classe / método / variável faz?
• Quão fácil é usar uma classe isoladamente (sem as outras classes) ou escrever uma unittest?

Primeiro, deixe seu código de lado pelo tempo que for prático. Trabalhe em outra coisa, algum outro pedaço de código. Mesmo depois de um dia, você ficará surpreso com o que encontrará.

Segundo, documente seu código. Muitos programadores odeiam documentar seu código, mas sente-se e escreva a documentação, como usar o código e como ele funciona. Ao olhar para o seu código de uma maneira diferente, você encontrará erros.

Já foi dito que o verdadeiro domínio de um assunto é a capacidade de ensiná-lo a outra pessoa. Com a documentação, você está tentando ensinar a outra pessoa seu código.

Transforme esta técnica de depuração em uma técnica de revisão de código: http://en.wikipedia.org/wiki/Rubber_duck_debugging

O conceito faz maravilhas para colocar você em uma mentalidade adequada para trabalhar com o código como se fosse novo.

Além das ferramentas úteis mencionadas em outras respostas, acho que modificar sua mentalidade é útil ao fazer uma revisão de código. É bobagem, mas digo a mim mesmo: "Estou colocando meu chapéu de revisão de código". Eu faço o mesmo com o controle de qualidade.

Então é importante limitar- se a essa mentalidade. Você é o revisor ou o revisor, não pode ser os dois ao mesmo tempo. Portanto, como revisor, tomo notas objetivas para compartilhar com o revisor. Não altero o código durante a revisão; isso não é algo que um revisor deva fazer.

A formalidade parece um pouco absurda às vezes, mas eu acho que quando trabalho sozinho, muitas vezes sou levada a muitas direções. Portanto, talvez eu não feche necessariamente o ciclo de revisão antes que algo mais apareça - que a formalidade (e realmente, estou falando notas brutas em uma ferramenta wiki) é útil para garantir que a revisão seja feita. Da mesma forma, com meu chapéu de controle de qualidade, adiciono tickets para erros antes de corrigi-los.

Parece que o sentimento comum é que a autoavaliação não é eficaz. Discordo e acho que a autoavaliação pode capturar muitos problemas se for feita minuciosamente.

Aqui estão algumas dicas dos meus poucos anos de experiência:

• Tenha à mão uma lista de verificação aproximada. Essas são as coisas que você deseja sinalizar enquanto lê seu código.
• Coloque sua revisão de código offline. Pode parecer um desperdício, mas faça impressões que você possa anotar e alternar entre si, ou o equivalente digital de PDFs bem destacados, sincronizados com um iPad, que será colocado offline. Afaste-se da sua mesa, para que tudo o que você faça é revisar seu código sem distrações.
• Faça isso de manhã cedo, e não no final de um dia útil. Par de olhos novo é melhor. De fato, pode ser útil ficar longe do código um dia antes de revisá-lo novamente.

Apenas um FYI - essas diretrizes faziam parte das recomendações da Oracle há alguns anos atrás, quando eu trabalhava lá, onde o objetivo era capturar bugs "upstream" antes que o código fosse testado. Ajudou muito, embora tenha sido considerado um trabalho chato por muitos desenvolvedores.

A técnica de Processo de software pessoal para revisões pode ser útil, embora se baseie em dados históricos sobre o seu trabalho e a qualidade dos produtos.

Você começa com dados históricos sobre seus produtos de trabalho, especificamente o número e os tipos de defeitos. Existem vários métodos de classificação de defeitos, como este de um curso PSP . Você pode desenvolver o seu próprio, mas a idéia é que você precisa saber quais erros você está cometendo ao longo do caminho.

Depois de saber quais erros você está cometendo, você pode desenvolver uma lista de verificação que pode usar durante uma revisão. Esta lista de verificação abrangeria os principais erros que você está cometendo e acha que podem ser capturados em uma revisão (em vez de usar outra ferramenta). Toda vez que você revisar um produto de trabalho, use a lista de verificação e procure esses erros ou erros, documente-os e corrija-os. Revise periodicamente esta lista de verificação periodicamente para garantir que você esteja se concentrando em problemas reais e relevantes em seu código.

Eu também recomendaria usar o suporte de ferramentas quando isso fizer sentido. As ferramentas de análise estática podem ajudar a encontrar alguns defeitos, e algumas até suportam a verificação de estilo para impor consistência e bom estilo de código. O uso de um IDE com conclusão de código e destaque de sintaxe também pode ajudar a prevenir ou detectar alguns problemas antes de clicar em "criar". Os testes de unidade podem cobrir problemas lógicos. E se o seu projeto for suficientemente grande ou complexo, a integração contínua pode combinar tudo isso em um processo executado regularmente e produzir bons relatórios para você.

Trabalhar sozinho significa que, a menos que você confie em completos estranhos para revisar o código em seu nome, precisará analisar a maneira como escreve seu software para manter a qualidade do código.

Primeiro e acima de tudo, você deve ter um meio de garantir que seu código corresponda aos requisitos e, segundo, que seu código será relativamente fácil de alterar se você decidir mais tarde que algo está errado. Minha sugestão seria aplicar uma abordagem de desenvolvimento orientado a comportamentos pelos seguintes motivos:

1. BDD significa escrever o teste de código primeiro. Isso garante que todo o seu código seja coberto por testes.
2. O BDD é essencialmente TDD, mas com um foco e "linguagem" ligeiramente diferentes. O que isso significa é que você refatora continuamente seu código enquanto trabalha nele e usa seus testes para garantir que seus esforços de refatoração continuem para garantir que seu código atenda às especificações do produto.
3. A linguagem BDD incentiva os testes a serem escritos na forma de instruções que essencialmente codificam requisitos como testes de unidade.

Portanto, a idéia aqui é que sua refatoração contínua de código, mesmo após a aprovação dos testes, significa que você está efetivamente revisando seu próprio código e usando seus testes de unidade como o "par extra de olhos", para garantir que seu código não seja " • desviar-se dos requisitos que são codificados nos testes. Além disso, a alta cobertura de teste com base nos requisitos garante que você poderá alterar seu código no futuro sem falhar nos requisitos.

O problema real para você será se você pode ou não detectar possíveis problemas no seu código que indicarão a necessidade de refatorar. Existem várias ferramentas de criação de perfil no mercado que podem ajudá-lo com isso, além de várias outras ferramentas relacionadas às métricas de qualidade de código. Isso geralmente pode lhe dizer muitas coisas que as revisões de código podem perder e são uma obrigação ao desenvolver projetos por conta própria. Na realidade, porém, a experiência é a chave e, quando você tem o hábito de ser impiedoso em sua refatoração, provavelmente se tornará muito mais crítico em relação ao seu próprio código. Se você ainda não o fez, sugiro ler o livro de Refatoração de Martin Fowler como ponto de partida e procurar uma boa API BDD que você acha que funcionará para você no idioma que você escolheu trabalhar.

Sempre que estou na mesma situação que você, tentei resolver o problema de "estar muito perto do código para examiná-lo objetivamente" usando ferramentas de revisão / métrica de código. Escusado será dizer que uma ferramenta não pode dar o mesmo valor que um revisor experiente, mas você ainda pode usá-las para identificar áreas de mau design.

Uma ferramenta que achei bastante útil nesse sentido foi o SourceMonitor . É um pouco simplista, mas fornece uma boa opinião de nível médio do seu código, como o número de métodos em uma classe e a complexidade de cada método. Sempre achei que esse tipo de informação era tão importante (se não mais importante que) a imposição de estilos de codificação por meio de ferramentas como StyleCop, etc (que são importantes, mas geralmente não são a fonte dos maiores problemas). Use essas ferramentas com as isenções de responsabilidade usuais: saiba quando quebrar uma regra de ouro e algo que é todo verde em uma ferramenta de métrica de código não é automaticamente de boa qualidade.

Não sei dizer quantas vezes expliquei algo a um revisor de códigos e a lâmpada na minha cabeça acende e diz: "Ei, espere um minuto". Por isso, frequentemente encontro meus próprios erros na revisão de código que a outra pessoa não viu. Para tentar, basta começar a explicar o código como se houvesse uma pessoa sentada ao seu lado tentando entender o que você fez e por quê.

Outra coisa que encontro frequentemente nas análises de código é que o desenvolvedor não seguiu realmente o requisito. Portanto, comparando seu código e o que ele faz, o requisito real é uma boa verificação.

Freqüentemente fazemos coisas como pacotes SSIS que têm necessidades estruturais semelhantes - para revisões de código, desenvolvi uma lista de verificação a ser verificada (a configuração está correta, está configurada em log, usa o banco de dados de metadados, os arquivos no local padrão, etc.) Você pode ter algumas coisas que seriam úteis para verificar sempre em uma revisão de código. Sente-se e pense no que você colocaria em uma lista de verificação das coisas que deseja verificar na revisão de código (Primeiro item, verifique se o requisito foi atendido, o próximo item pode ter algo a ver com erros de interceptação e registro). Ao cometer erros e corrigi-los, você pode adicionar outros itens à lista (digamos algo como, eu passo para o próximo registro em um loop ou vou repetir infinitamente o mesmo primeiro item - leva apenas um loop infinito para ensiná-lo a procurar por isso!).

Dê três meses e volte e veja seu código. Eu prometo a você, se você não consegue encontrar algo errado com isso (ou pergunta quem escreveu esse lixo!), Você é um homem melhor do que eu!

Normalmente, imprimo todo o meu código e sento-me em um ambiente silencioso e o leio, encontro muitos erros de digitação, problemas, coisas para refatorar, limpeza ao fazer isso. É uma boa autoavaliação que acho que todos deveriam fazer.

De volta à faculdade, eu era um tutor de redação. Certamente me deu algumas perspectivas sobre codificação que eu acho que muitos desenvolvedores nunca teriam pensado. Um dos mais importantes é ler seu código em voz alta. Não parece muito, mas darei um exemplo perfeito com o qual acho que todos podem se identificar.

Você já escreveu um e-mail ou um artigo, releu várias vezes para se certificar de que está correto e o enviou, apenas para descobrir que possui um erro de ortografia flagrante, erro de digitação ou erro gramatical? Ontem fiz isso ontem quando pedi a um cliente para pressionar a tecla Shit em vez da tecla Shift. Quando você lê na sua cabeça - você vê o que deseja ver.

Este é um atalho para as sugestões "apenas espere um dia, uma semana ou um mês" que outras pessoas fizeram. Se você lê em voz alta, você pega as mesmas coisas. Não sei por que é tão eficaz, mas depois de sentar com centenas de estudantes e fazê-los ler em voz alta, tudo o que posso dizer é que funciona.

A maioria das pessoas tende a considerar seu código como seu próprio bebê e alimenta-o com o ego e não com a realidade. Assim como qualquer outra revisão de código, revise-a enquanto vê o código de outra pessoa. Esquecer completamente que você escreveu algo. Revise cada linha do código. Uma lista de verificação seria útil por ser estética sobre a revisão do próprio código. Ferramentas automatizadas para revisão de código podem ajudar em certa medida. Eu usei algumas ferramentas como o klocwork (software comercial). Isso é bastante útil enquanto você trabalha em grandes projetos e vários desenvolvedores estão trabalhando para isso. Sempre foque na detecção de defeitos em vez de na correção.

Mas uma prática recomendada seria, revise a si mesmo e depois envolva pelo menos duas outras pessoas para revisão com funções distintas.

Considere fazer uma inspeção de Fagan por conta própria - você terá que adaptar o processo porque está sozinho, mas poderá obter um pouco de valor disso. O truque será encontrar o "conjunto de regras" certo para avaliar seu código como um desenvolvedor solo e, em seguida, ter a disciplina para fazer essas perguntas em um estado de espírito crítico, analítico e impiedoso a cada vez. Eu suspeito que você pode querer debater suas próprias 4-5 perguntas cruciais para começar e depois evoluí-las ao longo do tempo. Algumas pessoas são contra inspeções formais porque parecem ter muito tempo ... antes de você decidir que são caras demais, lembre-se de todas as evidências estatísticas de que fazer inspeções corretamente reduz o tempo do projeto. Aqui está um link da Wikipedia com o qual você pode iniciar mais pesquisas:

http://en.wikipedia.org/wiki/Software_inspection

Também existem alguns livros, como o Google for "Software Inspection Process", de Strauss e Ebenau.

Outra opção é pagar alguém para inspecionar um projeto importante - ou talvez pagar ocasionalmente para fazer inspeções em todo o seu código. Esse cara é muito bom, nós o expulsamos várias vezes para treinar nossos desenvolvedores mais recentes:

http://www.javaspecialists.eu/

Além de todas as recomendações para revisão de código, você pode usar ferramentas como PMD e findBug para garantir o primeiro nível de sanidade do seu código.

Na verdade, isso ainda não foi colocado em uma resposta (mas foi adicionado como um comentário a uma resposta existente)

Revise seu código após uma boa noite de sono, por exemplo, comece o dia revisando o código que você escreveu no dia anterior.

Obviamente, isso não fornecerá a você a experiência coletiva de uma equipe, mas permitirá revisar o código de uma nova perspectiva.

Por exemplo, se você deixou um pedaço de código com um truque desagradável, pode não estar muito inclinado a corrigi-lo, se revisar seu código imediatamente depois. Afinal, quando você começa a revisar seu código, você já sabe e aceitou a presença desse hack. Mas se você teve uma boa noite de sono, provavelmente está mais motivado a encontrar uma solução melhor.

Quando dormimos, o cérebro não para de trabalhar nos problemas que temos, então você pode encontrar uma solução lá, embora essas soluções às vezes se apresentem de maneiras estranhas .