Como evitar erros de digitação, etc?

4

Pela primeira vez, tenho codificado para um software de código aberto, onde todo o meu trabalho é revisado antes de ser confirmado. Eu entendo que revisar o trabalho não é uma tarefa fácil, então não gosto de desperdiçar tempo e esforço dos revisores. Mas muitas vezes eu cometi erros de digitação e erros de outro tipo enquanto fazia uma alteração no código.

Por exemplo, a última vez que refatorei algum código antigo, movi o código de uma classe para outra, mas esqueci de verificar que $this só funcionava na classe antiga e precisava ser alterado agora.

Eu executo testes de unidade, mas às vezes eles perdem esses erros (nós temos cobertura de teste incompleta agora). E eu concordo que muitas vezes eu tenho pressa em enviar a mudança apenas para fazer o trabalho mais rápido.

Mas, além de desperdiçar o tempo dos revisores, isso realmente retarda o processo de desenvolvimento e reduz minha credibilidade (pequenos erros podem até esconder elogios por um bom trabalho).

Qual é a melhor maneira de evitar esse cenário ou, em outras palavras, como posso revisar meu próprio código antes que alguém o faça?

Edit: Eu uso o Notepad ++ para PHP, por favor, não me peça para mudar o IDE imediatamente; no entanto, sugestões são bem-vindas se forem persuasivas;)

    
por nischayn22 28.07.2012 / 18:16
fonte

8 respostas

8

Você já respondeu à sua pergunta sozinho.

Existem várias coisas que devemos sempre lembrar ao desenvolver (não importa qual idioma, IDE, projeto está em sua mesa):
- Ao desenvolver, tente pensar apenas sobre o projeto no qual você está trabalhando. Todo o resto deve ser esquecido por um tempo, incluindo o elogio que você terá se fizer bem o seu trabalho. Tais pensamentos apenas o distrairão e você cometerá mais erros como resultado.
- Não se apresse , se não for vital para o projeto. Tome seu tempo, tente testar tudo corretamente. Como você mencionou, o código rápido, mas cheio de bugs, não é algo para se orgulhar. Tenho certeza que se você não se apressar tanto, será capaz de detectar muitos bugs sozinho.

E, como mencionado em outras respostas, execute testes de unidade. E mais um. Sempre haverá bugs. Ninguém é perfeito. Mas essas duas regras ajudarão você a reduzir a quantidade delas.

    
por 28.07.2012 / 18:45
fonte
9

I do run tests, but sometime they miss these errors (incomplete test coverage).

Depois que seu erro for descoberto, considere adicionar um novo teste que impeça os futuros contribuidores de repetir esse erro ou, melhor ainda, todo tipo de erro como este.

Se isso for feito corretamente, melhorar a cobertura de testes e testes de regressão compensarão suficientemente os danos causados por seu erro.

    
por 28.07.2012 / 18:42
fonte
5

- A abordagem de senso comum seria taking your time e revisaria seu código antes de marcar seu trabalho. Além disso, tente maximize your focus/concentration pela paz de trabalho que você está designado a fazer.

- A primeira abordagem prática seria usar re-factoring tools like JustCode ou similar uma vez. Eles improve your productivity e você pode ajustá-lo para erros de sintaxe .

- A segunda abordagem prática seria usar abordagem de TDD . Ele irá certificar-se de que seu código tenha testes adequados para funcionar (passar todos os testes de unidade necessários), caso contrário ele falhará.

Embora o TDD leve tempo para implementar e refatorar o código existente conforme necessário, é uma maneira limpa de escrever um código confiável e sólido.

    
por 28.07.2012 / 18:45
fonte
2

Depende da linguagem de programação. Uma linguagem com tipagem estática estrita e uma etapa de compilação no processo de compilação detectará a maioria dos erros de digitação; quanto mais estrita a linguagem, maior a chance de um erro de digitação causar uma sintaxe inválida. Um exemplo extremo é a linguagem de programação Haskell - os programadores de Haskell costumam dizer, meio brincando, que uma vez que um programa Haskell compila, é geralmente correto e livre de erros. Ainda há erros de digitação que passam pela rede; um exemplo famoso é = vs. == em C / C ++. O estilo de codificação pode fornecer alguma proteção extra; análise de código estático pode detectar código suspeito; um editor de texto com preenchimento automático reduz a chance de erros de digitação; mas, em última análise, não há substituto para testes reais.

Se você usa uma linguagem dinâmica, as coisas são mais terríveis - normalmente, não há etapa de compilação, então os erros all surgem como erros de runtime, mas nenhum impede a implantação por natureza. Pior ainda, muitos erros só serão percebidos quando o código incorreto for executado. Isso torna o teste (automatizado) ainda mais importante do que com linguagens compiladas estáticas estritas.

Mas, os testes automatizados têm seu próprio problema: cobertura. Para testes automatizados para capturar todos os erros, você precisa de 100% de cobertura de código (ou seja, seus testes devem tocar em todas as linhas de código), mas também precisa de 100% de cobertura de entrada (seus testes devem chamar cada unidade com todos os possíveis , em todos os estados possíveis do contexto). 100% de cobertura de código é factível, mas 100% de cobertura de entrada é difícil de ser impossível para qualquer coisa não trivial. Sua melhor aposta é fazer suposições sobre os conjuntos de insumos que podem atingir os casos específicos e esperar que você não perca nenhum. E como os testes são (por necessidade) escritos por humanos, você pode cometer erros ao escrever testes como erros ao escrever o código a ser testado. Felizmente, na maioria das vezes, um bug no teste não cancela um bug no código testado, mas faz com que o teste falhe duplamente.

Veja o que você pode fazer para evitar e atenuar erros de digitação:

  • Seja religioso sobre a unidade testando tudo.
  • Configure seu ambiente de desenvolvimento para executar todos os testes automaticamente: se você tiver um sistema de integração contínua em vigor, configure-o para executar todos os testes de unidade em cada construção e considere qualquer construção quebrada se algum teste falhar. Caso contrário, considere usar ganchos de controle de origem ou recursos semelhantes para executar testes antes de empurrar suas alterações para o upstream.
  • Codifique defensivamente, evite truques "inteligentes", use recursos dinâmicos de forma conservadora.
  • Se a sua linguagem de programação tiver opções para ser mais rígida (por exemplo, Option Strict e Option Explicit no VisualBasic), ative-as.
  • Se a sua linguagem de programação puder avisar sobre códigos suspeitos, faça isso (não em sistemas de produção) e trate cada aviso como um erro fatal.
  • Faça bom uso das salvaguardas incorporadas no idioma (por exemplo, insinuações de tipo do PHP).
  • Use um editor de código que forneça o preenchimento automático; usá-lo.
  • Ao nomear identificadores, evite "quase erros": não use $User e $user dentro do mesmo contexto.
  • Mantenha seu escopo o mais pequeno possível: evite o estado global, exponha somente o que precisa, evite efeitos colaterais etc. Isso evita tocar acidentalmente em locais completamente diferentes e torna seu código mais fácil de testar.
  • Peça a alguém para rever seu código.

Nada disso é à prova de balas, mas combiná-las abrange a maioria de suas bases e reduz o risco, esperançosamente, a níveis aceitáveis.

    
por 28.07.2012 / 23:24
fonte
1

Eu continuei cometendo erros parvos parecidos. A solução que encontrei foi o teste de unidade. Você configura uma série de testes automatizados para verificar a exatidão de seu código à medida que você o escreve.

    
por 28.07.2012 / 18:40
fonte
1

Escreva seu código em uma linguagem compilada .

EDIT: Não estou propondo que esta seja uma solução à prova de balas, mas certamente ajudará você a evitar muitos erros de digitação.

    
por 28.07.2012 / 18:50
fonte
0

Encontre alguém que possa revisar seu código sem constranger você.

Um dos seus problemas é que você sente que está perdendo a cara quando o projeto inteiro revisa seu código e encontra erros. Talvez haja alguém no projeto ou não com quem você possa fazer par com o seu código. Compartilhamento de tela, screencasts, correções, trabalho em outro ramo, etc., qualquer um desses métodos pode ser usado para compartilhar o código antes que o restante da equipe do projeto consiga vê-lo.

Em troca, claro, você deve oferecer o mesmo ou outro serviço a essa pessoa, por exemplo, se você fizer o dobro de artista, poderá fornecer ícones ou o que precisar.

Certifique-se de que um erro do passado não pode acontecer novamente

Isso é mais fácil em uma linguagem tipada, mas se você descobrir que ocasionalmente escreve $ thsi em vez de $, por exemplo, ative o corretor ortográfico do seu editor. Se for algo mais complicado, tente escrever um caso de teste que o detecte.

Por exemplo, algumas vezes cometi erros ao editar arquivos de propriedade usados para internacionalização, de modo que não havia valor em inglês para algumas chaves. Eu consertei os arquivos e, em seguida, escrevi um teste que carregou todas as chaves de uma vez e falhou, se alguma estivesse faltando.

Invista em melhores ferramentas / idiomas

Se houver um editor melhor do que o que você está usando, use-o. Se houver uma linguagem melhor que a que você está usando, use-a. Naturalmente, 'melhor' depende de vários fatores, um dos quais é o código que você já tem no projeto. Se a linguagem de destino é realmente muito ruim, você pode até gerar código de uma linguagem melhor. Há coisas que você perde fazendo isso, mas é bom estar ciente dessa opção. Na prática, eu só tive que fazer isso uma vez, quando recebi alguns requisitos para algum código Java muito repetitivo que tinha que ser totalmente documentado. Eu gerou 3000 linhas de código Java a partir de 50 linhas de outra linguagem.

    
por 29.07.2012 / 16:49
fonte
0

Uma biblioteca de ortografia, como Hunspell ou Aspell pode ser integrado no seu programa:

library(hunspell)

# Check individual words
words <- c("beer", "wiskey", "wine")
correct <- hunspell_check(words)
print(correct)
# [1]  TRUE FALSE  TRUE

seu editor:

ouseupipelinedeconstrução:

spellcheckHTML:image:tmaier/hunspell:latestscript:-exportHUNSPELL_FINDINGS='hunspell-l-iUTF-8-dde_DE_neu,en_US-p.words-Hpublic/**/*.html|sort|uniq'-echo$HUNSPELL_FINDINGS-test"$HUNSPELL_FINDINGS" == ""
dependencies:
  - build
stage: test
allow_failure: true

Crie um arquivo de dicionário personalizado para verificar a ortografia do jargão específico do projeto usando a funcionalidade "Adicionar ao dicionário" do seu editor de escolha.

Referências

por 12.10.2018 / 14:20
fonte