Como ser um programador de erro zero? [fechadas]

168

Meu chefe sempre me disse que um bom programador deve ser capaz de garantir que o código que ele altera seja confiável, correto e completamente verificado; que você deve entender completamente todos os resultados e impactos que suas alterações causarão. Eu tentei o meu melhor para ser esse tipo de programador - testando repetidamente - mas os bugs ainda estão lá.

Como posso ser um programador com zero erros e saber o que cada caractere do meu código causará e afetará?

user8
fonte
Na verdade, ninguém cria código perfeito da primeira vez, exceto eu. Mas há apenas um de mim. - Tech Talk: Linus Torvalds no git, Google, 15 de agosto de 2007 izquotes.com/quote/273558
JensG
Não existe programação com 0 bug. Leia o matemático Godel para entender o porquê.
Michael Martinez
É um objetivo errado, consulte: yegor256.com/2015/06/18/good-programmers-bug-free.html
yegor256

Respostas:

365

Não codifique nada.

Essa é a única maneira de você ser um programador com zero erros.

Os bugs são inevitáveis ​​porque os programadores são humanos, tudo o que podemos fazer é tentar o nosso melhor para evitá-los, reagir rapidamente quando um bug ocorre, aprender com nossos erros e manter-nos atualizados.

picos selvagens
fonte
73
+1 Acompanhamento: Ou você pode se tornar um arquiteto sem codificação (torre de marfim) e ainda receber muito pagamento! Essa é a melhor.
Martin Wickman
26
Errar é humano, consertar seus erros divinos.
Ward Muylaert
11
Eu costumava ter uma colega de trabalho que era favorecida pelo chefe porque ela consistentemente tinha uma pequena contagem de bugs. Como ela fez isso? Simples, ela atribuiu os bugs que não queria a outra pessoa e sempre assumiu os recursos mais fáceis / menores.
toby
46
Não sei quem disse isso primeiro, mas "Se a depuração é o processo de remoção de erros, a programação deve ser o processo de colocá-los".
Bruce Alderman
8
Melhor ainda: torne-se um chefe e faça com que seus subordinados se sintam infelizes sem ter que se responsabilizar por nada.
precisa saber é
124

Zero bugs é impossível para um programa não trivial.

É possível chegar muito perto, mas a produtividade sofre. E vale a pena apenas para determinados softwares de alto risco. O software Space Shuttle me vem à mente. Mas sua produtividade é da ordem de algumas linhas por dia. Duvido que seu chefe queira isso.

Este software está livre de erros. É perfeito, tão perfeito quanto os seres humanos alcançaram. Considere estas estatísticas: as três últimas versões do programa - cada uma com 420.000 linhas - tiveram apenas um erro cada. As últimas 11 versões deste software apresentaram um total de 17 erros.

Faça a atualização do software para permitir que o ônibus navegue com os satélites de posicionamento global, uma alteração que envolve apenas 1,5% do programa, ou 6.366 linhas de código. As especificações para essa alteração executam 2.500 páginas, um volume mais grosso que uma lista telefônica. As especificações para o programa atual preenchem 30 volumes e executam 40.000 páginas.

CodesInChaos
fonte
3
Não é impossível. Mas altamente improvável.
quer
36
O que faz você pensar que o FB está livre de erros? O modelo de segurança e privacidade do Facebook é um erro enorme. Por exemplo, a conta do Facebook dos chefes do Facebook foi invadida na semana passada devido a problemas de segurança.
Stephen C
6
A filosofia do @Elaine Facebook é "ir rápido e quebrar as coisas" ( geek.com/articles/news/… ) e eles tiveram inúmeros bugs ( facebook.com/board.php?uid=74769995908 ), incluindo muitos que eu já corri dentro de mim. O Twitter não é diferente, conhecido por estar frequentemente fora do ar ( engineering.twitter.com/2010/02/anatomy-of-whale.html ) e erros como o "follow bug" ( status.twitter.com/post/587210796/… )
Yevgeniy Brikman
9
Não se esqueça dos postes em movimento. Um recurso no seu PerfectProgram 1.0 pode ser um bug no 2.0
Carlos
4
@CodesInChaos: A teoria diz que existem programas para os quais é impossível provar seu comportamento. Não diz que é impossível provar o comportamento de todos os programas. Eu acho que a maioria dos programas comuns é do tipo comprovável, e alegar que "é impossível que meu código esteja livre de erros por causa do problema de parada" é uma aplicação incorreta da teoria.
endolith 23/01
98

"Programador de bug zero" é um oxímoro, como um cantor silencioso, mas os últimos 60 anos de programação produziram alguns pedaços de sabedoria, o que o tornará um programador melhor, como:

  • Seja humilde - você é e estará cometendo erros. Repetidamente.
  • Esteja ciente do tamanho limitado do seu crânio. Aproxime-se da tarefa com total humildade e evite truques inteligentes como a praga. Edsger Dijkstra
  • Combater explosão combinatória
  • Livre-se do estado mutável (sempre que possível). Sim, aprenda programação funcional.
  • Reduza o número de caminhos de código possíveis
  • Entenda (a magnitude) do tamanho dos espaços de entrada e saída (de suas funções) e tente reduzi-los para se aproximar cada vez mais da cobertura de teste de 100%
  • Sempre assuma que seu código não está funcionando - prove o contrário!
Maglob
fonte
2
Ficaria feliz em provar que meu código está funcionando ... mas os testes só podem provar que não. Você está falando de prova formal ou visualizando a tarefa de depuração aqui?
Matthieu M. 30/01
Primeira resposta útil neste tópico. @ Matthieu: Você pode provar, para cada combinação possível de dois bytes, que uma função retornará um resultado correto (por exemplo: max), que é um byte novamente. Você pode ter duas ou mais funções desse tipo e agora pode encadeá-las e obter um grande número de combinações possíveis dessas funções, que novamente produzirão apenas um byte. A idéia de que você só pode provar que algo está errado está errada. Popular, mas errado.
usuário desconhecido
@ Matthieu M .: O teste prova que as coisas estão funcionando como você espera. Se você pode provar que todos os itens estão funcionando da maneira que você espera, a partir daí você prova que está lidando com o comportamento de entrada que não esperava. Depois de definir qual é esse comportamento e qual deve ser, você escreve um novo teste para ele. Agora faz parte do seu comportamento esperado.
deworde
1
@deworde: Eu entendo a ideia de testar, mas, além de situações de nicho, a maior parte do trabalho real que fiz não pôde ser testada exaustivamente, simplesmente porque o número possível de combinações era muito grande (e nem estou adicionando questões de tempo). Assim, além de situações de nicho, os testes só ir tão longe (ainda é útil para verificar que pelo menos o caso nominal passar!)
Matthieu M.
"evite truques inteligentes como a praga" - isso por si só seria uma boa resposta. Como é - é ótimo.
2121
25

TDD

O objetivo do TDD é que você não escreva uma única linha de código se não houver um teste exigindo essa linha de código. E para levar ao extremo, você sempre começa a desenvolver um novo recurso escrevendo um teste de aceitação. Aqui eu descobri que escrever testes de estilo de pepino é ideal.

A abordagem TDD oferece pelo menos dois benefícios.

  • Todo o código é escrito para resolver um recurso específico, portanto, sem superprodução desnecessária.
  • Sempre que alterar uma linha de código existente, se você quebrar um recurso, você será notificado

Não prova zero bugs, pois isso seria impossível (já foram apontados por inúmeras outras respostas). Mas depois de aprender o TDD e me tornar bom nisso (sim, também é uma habilidade que precisa ser praticada), tenho uma confiança muito maior no meu próprio código, porque ele é exaustivamente testado. E, mais importante, posso alterar o código existente que não compreendo completamente sem me preocupar com a quebra de funcionalidade.

Mas o TDD não ajuda em nada. Você não pode escrever um código sem erros se não entender completamente a arquitetura do sistema e as armadilhas dessa arquitetura. Por exemplo, se você estiver escrevendo um aplicativo Web que lida com várias solicitações simultaneamente, deve saber que não pode compartilhar dados mutáveis ​​entre várias solicitações (não caia na armadilha para iniciantes para armazenar em cache dados mutáveis ​​para melhorar o desempenho).

Acredito que as equipes de desenvolvimento que são boas em TDD entregam o código com o menor número de defeitos.

Pete
fonte
19

O problema é que bugs são coisas que você não reconhece. A menos que você tenha algum tipo de conhecimento enciclopédico da linguagem de programação / compilador, bem como de todos os ambientes em que seu aplicativo será executado, você realmente não pode esperar produzir código 100% livre de erros.

Você pode reduzir sua contagem de bugs através de muitos testes, mas no final provavelmente haverá alguns casos adicionais que não serão contabilizados. Joel Spolsky escreveu um artigo particularmente interessante sobre correção de bugs .

user7007
fonte
1
+1. Nas palavras de Twisted Sister, o que você não sabe com certeza pode machucá-lo / O que você não pode ver o faz gritar.
Engenheiro de
17

Sim, é impossível nunca ter um erro no seu código, mas não é impossível ter menos erros. A atitude de que "isso é idiota, você sempre terá bugs" é apenas uma bobagem para evitar reduzir o número de bugs no seu código. Ninguém é perfeito, mas podemos e devemos nos esforçar para melhorar. Em meus próprios esforços para melhorar, achei os seguintes pontos úteis.

  • Isso não é fácil. Você não vai melhorar durante a noite. Portanto, não desanime e não desista.
  • Escreva menos e escreva com mais inteligência. Menos código é tipicamente melhor. É natural querer planejar com antecedência e tentar criar padrões de design impressionantes, mas, a longo prazo, apenas escrever o que você precisa economiza tempo e evita bugs.
  • A complexidade é o inimigo. Menos não conta se for uma confusão complicada obscura. O código de golfe é divertido, mas é um inferno para entender e um inferno para depurar. Sempre que você escreve código complicado, você se abre para um mundo de problemas. Mantenha as coisas simples e curtas.
  • A complexidade é subjetiva. O código que antes era complicado se torna simples quando você se torna um programador melhor.
  • Experiência é importante. Uma das duas maneiras de se tornar um programador melhor é praticar. A prática NÃO é escrever programas que você sabe escrever com facilidade, mas escrever programas que machucam um pouco e fazem você pensar.
  • A outra maneira de melhorar é ler. Existem muitos tópicos difíceis na programação para aprender, mas você nunca poderá aprendê-los apenas pela programação, precisa estudá-los. Você precisa ler as coisas difíceis. Coisas como segurança e concorrência são impossíveis de aprender corretamente, basta escrever código, a menos que você queira aprender limpando desastres. Se você não acredita em mim, veja os sites épicos sobre questões de segurança que o Gawker tinha. Se eles tivessem tempo para aprender como fazer a segurança corretamente e não apenas criar algo que funcionasse naquela confusão, nunca teria acontecido.
  • Leia blogs. Existem muitos blogs interessantes por aí que oferecem maneiras novas e interessantes de ver e pensar em programação, isso ajudará você a ...
  • Aprenda os detalhes sujos. Os pequenos detalhes de como partes obscuras do seu idioma e aplicativo funcionam são muito importantes. Eles podem conter segredos que o ajudam a evitar a codificação de códigos complicados ou podem ser partes com bugs que você precisa evitar.
  • Aprenda como os usuários pensam. Às vezes, seus usuários são completamente loucos e trabalham com seu aplicativo de maneiras que você não entende e não pode prever. Você precisa entrar na cabeça o suficiente para saber as coisas mais estranhas que eles podem tentar e garantir que seu aplicativo possa lidar com isso.
AmaDaden
fonte
8

Pessoalmente, acho que a luta pela programação sem erros parece ser mais cara (em tempo e dinheiro). Para atingir zero bug, ou mesmo quase zero, é necessário que os desenvolvedores testem completamente. Isso significa testar a regressão antes de enviar qualquer código para a revisão do patch. Esse modelo não me parece econômico. É melhor que os desenvolvedores realizem testes diligentes e deixem os testes detalhados para a equipe de controle de qualidade. Aqui está o porquê:

  • Os desenvolvedores são péssimos nos testes. É verdade e você sabe disso. (Eu sou um desenvolvedor!) Uma boa equipe de controle de qualidade sempre encontrará os casos críticos em que os desenvolvedores nunca pensam.
  • Os desenvolvedores são bons em codificação. Deixe-os voltar ao que se destacam (e geralmente ao que preferem fazer de qualquer maneira).
  • A equipe de controle de qualidade pode encontrar erros relacionados a várias tarefas do desenvolvedor de uma só vez.

Aceite que, ao escrever o código, haverá erros registrados nele. É por isso que você tem um processo de controle de qualidade e tudo faz parte de ser um desenvolvedor. Claro que isso não significa que você envie algo assim que escrever seu último ponto e vírgula. Você ainda precisa garantir a qualidade do seu trabalho, mas pode exagerar.

Quantas profissões você pode citar que sempre realizam suas tarefas corretamente da primeira vez, sem revisão por pares e / ou testes?

Sebastien Martin
fonte
8

Zero bugs? Parece que você precisa do Lisp (siga o caminho cético e evite o videoclipe).

É extraordinariamente difícil obter código sem erros nos ambientes de codificação convencionais (Java, C #, PHP, etc.). Eu focaria na produção de código bem testado e revisado por pares em iterações curtas e controladas.

Manter o código o mais simples possível ajudará a evitar erros.

Verifique se você está usando ferramentas de análise de código (como FindBugs , PMD e assim por diante) que, combinadas com avisos estritos do compilador, revelarão todo tipo de problema com seu código. Tome nota do que eles estão dizendo, realmente se esforce para entender qual é a natureza do bug e, em seguida, tome medidas para alterar seu idioma de programação, para que não pareça natural codificar de uma maneira que introduza esse bug novamente.

Gary Rowe
fonte
3
Às vezes, os bugs são como monstros escondidos que vivem lá, eles se escondem durante meus testes repetidos e revisão de código pessoal ... mas depois que eu faço a revisão por pares, descobri que os monstros eram inacreditáveis ​​visíveis e saltaram para mim de repente. É realmente estranho. Dependendo apenas do 'olho' e 'cérebro' humanos, parece impossível tocar a linha livre de insetos. o teste de unidade não é viável para todos os casos. Ferramentas de análise de código? parece emocionante, eu nunca usei isso, vou fazer pesquisas nesse campo.
Elaine
Eu diria que você precisa de Ada, mas Lisp é mais divertido. ;-)
Orbling 30/01
1
@Elaine Onde trabalho é um ambiente Java e o código só pode ser compartilhado com a equipe se ele passou pelo Findbugs e PMD. Os novos membros da equipe passam por cinco estágios: negação, raiva, barganha, depressão e aceitação. Depois, eles nunca olham para trás.
Gary Rowe
@ Gary Rowe, eu entendo essas reações, lol, eu já estive em uma empresa onde havia um departamento de controle de qualidade. Os funcionários verificavam semanalmente todos os códigos produzidos naquela semana, para ver se todas as linhas de código estavam em conformidade com a regra ' '(Eu não tenho idéia se eles estavam usando algumas ferramentas como Findbugs / PMD), mas soa um pouco como a etapa em que você está.
Elaine
1
@ Gary: Nenhum argumento de mim, mas vários lugares em que trabalhei tratam as violações de estilo como equivalentes de bugs. E eles costumavam ter regras de estilo como "toda classe deve declarar os campos estáticos CLS_PKG e CLS_NAME que contêm os nomes dos pacotes e das classes". Geralmente, apoio padrões de codificação, mas não quando eles se transformam em coisas assim!
TMN
8

Todo o "Não codifique nada". as respostas estão completamente erradas. Além disso, seu chefe definitivamente não parece ser um idiota!

Não me lembro quantas vezes vi programadores que simplesmente não sabiam o que seu código faz. Sua única filosofia de desenvolvimento parecia ser tentativa e erro (e muitas vezes também copia / cola / modifica). Embora tentativa e erro seja uma maneira válida de solucionar alguns problemas, geralmente você pode analisar o domínio do problema e aplicar uma solução muito específica com base no seu entendimento das ferramentas utilizadas e com um pouco de disciplina e diligência, você não terá apenas resolveu o problema, mas também a maioria dos casos extremos (possíveis erros) antes de implantá-lo pela primeira vez. Você pode garantir que o código está livre de bugs? Claro que não. Mas a cada bug que você encontra ou lê sobre você pode adicioná-lo às coisas que você pode querer pensar na próxima vez que escrever / alterar alguma coisa. Se você fizer isso, ganhará, consequentemente, muita experiência em como escrever código quase sem erros. - Há toneladas de recursos disponíveis sobre como se tornar um programador melhor que pode ajudá-lo na jornada ...

Pessoalmente, eu nunca confirmaria código onde não posso explicar todas as linhas. Cada linha tem um motivo para estar lá, caso contrário, deve ser removida. É claro que às vezes você fará suposições do funcionamento interno dos métodos que você chama, caso contrário, você precisará conhecer a lógica interna de toda a estrutura.

Seu chefe tem toda a razão em dizer que você deve entender os resultados e o impacto do código que escreve no sistema existente. Ocorrerão erros? Sim, claro. Mas esses bugs se devem ao seu entendimento incompleto do sistema / ferramentas com que você trabalha e, a cada correção de bugs, você terá uma cobertura melhor.

Patrick Klug
fonte
"a cada bug que você encontra ou lê sobre você pode adicioná-lo às coisas que você deseja pensar na próxima vez que escrever / alterar alguma coisa", este é um ótimo ponto. Criei um documento do Google relacionado a bugs que vi ou codifiquei, apenas para esse fim.
Ben
7

Como os outros comentários já apontaram corretamente, não há software não trivial sem bugs.

Se você deseja testar o software sempre lembre-se, esses testes podem apenas provar a presença de bugs e não a sua ausência.

Dependendo do seu domínio de trabalho, você pode tentar a verificação formal do seu software. Usando métodos formais, você pode ter certeza de que seu software atende exatamente às especificações.

É claro que isso não significa que o software faça exatamente o que você deseja. Escrever uma especificação completa também não é possível em quase todos os casos. Basicamente, muda o local onde podem ocorrer erros da implementação para a especificação.

Portanto, dependendo da sua definição de "bugs", você pode tentar a verificação formal ou apenas tentar encontrar o maior número possível de bugs no seu software.

FabianB
fonte
6

Ou não escreva nada mais complicado do que "Olá Mundo!" ou se você disser a todos para nunca usá-lo.

Pergunte ao seu chefe alguns exemplos deste código chamado livre de bugs.

JeffO
fonte
5

Eu concordo com os outros. Aqui está como eu abordaria o problema

  • Obtenha um testador. Veja o teste Joel para saber o porquê.
  • Use bibliotecas extensivamente; o provavelmente foi melhor depurado. Eu sou um grande fã do CPAN para Perl.
Brian Carlton
fonte
1
… Mas se você usar bibliotecas, verifique se os bugs não podem arrastar você para baixo (por exemplo, tendo a fonte para que você possa auditá-la ou corrigi-los, se necessário).
millenomi
5

Você pode se esforçar para ser um programador de zero erros. Eu me esforço para ser um programador de zero erros sempre que escrevo código. No entanto, eu não

  • envolver várias técnicas de teste (exceto a ATDD)
  • criar verificações formais do nosso software
  • ter uma equipe de controle de qualidade separada
  • faça análises duras em cada alteração feita na base de código
  • use uma linguagem que incline mais a segurança e cautela

Eu não faço essas coisas porque elas são proibitivas em termos de custo para o software que escrevo. Se eu fizesse essas coisas, provavelmente estaria mais adiantado para zero bugs, mas não faria sentido nos negócios.

Crio ferramentas internas usadas por grande parte da nossa infraestrutura. Meus padrões para teste e codificação são altos. No entanto, há um equilíbrio. Não espero zero bugs porque não posso fazer com que as pessoas dediquem esse tipo de tempo a um trabalho. As coisas podem ser diferentes se eu estivesse criando o software para controlar uma máquina de raio X, motores a jato, etc. Nenhuma vida está em risco se meu software quebrar, por isso não nos comprometemos com esse nível de garantia.

Eu corresponderia o nível de garantia ao uso pretendido do software. Se você estiver escrevendo um código que o ônibus espacial da NASA usará, talvez seja razoável tolerância zero a erros. Você só precisa adicionar várias práticas adicionais e muito caras.

dietbuddha
fonte
4

Eu acho que um bom primeiro passo para se tornar um programador de "zero-bug" é mudar sua atitude em relação aos bugs. Em vez de dizer as coisas "elas acontecem", "melhor controle de qualidade e testadores" ou "os desenvolvedores são ruins no teste", diga:

Erros não são aceitáveis ​​e farei tudo ao meu alcance para eliminá-los.

Uma vez que isso se torne sua atitude, os erros cairão rapidamente. Na sua pesquisa para encontrar maneiras de eliminar bugs, você encontrará o desenvolvimento orientado a testes. Você encontrará muitos livros, postagens em blogs e pessoas oferecendo conselhos gratuitos sobre melhores técnicas. Você verá a importância de melhorar suas habilidades através da prática (como codificar katas ou experimentar coisas novas em casa). Você começará a ter um desempenho melhor no trabalho, porque começará a trabalhar em seu ofício em casa. E, esperançosamente, depois de ver que é possível escrever um bom software, sua paixão por seu ofício aumentará.

Darren
fonte
2

Em certo sentido, seu chefe está certo. É possível escrever um software que se aproxime de zero bugs.

Mas o problema é que o custo de escrever (quase) programas com zero erros é proibitivamente alto . Você precisa fazer coisas como:

  • Use especificações formais de seus requisitos. Formal, como no uso de Z ou VDM ou alguma outra notação matematicamente correta.

  • Use técnicas de comprovação de teoremas para provar formalmente que seu programa implementa a especificação.

  • Crie amplos conjuntos de unidades, regressões e testes de sistema e chicotes de fios para testar de todas as formas possíveis bugs. (E isso não é suficiente por si só.)

  • Ter muitas pessoas rever os requisitos (formais e informais), software (e provas). testes e implantações.

É extremamente improvável que seu chefe esteja preparado para pagar por tudo isso ... ou aguentar o tempo necessário para fazer tudo.

Stephen C
fonte
1

Atingi o status "zero bug". Eu digo aos meus usuários que é um recurso não documentado ou eles estão solicitando um novo recurso e, portanto, é um aprimoramento. Se nenhuma dessas respostas for aceita, digo apenas que elas não entenderam seus próprios requisitos. Portanto, não há bugs. Programadores são perfeitos.

giulio
fonte
1

Aqui estão as etapas para criar um programa sem erros:

  1. Nunca comece a codificar, a menos que você tenha ESPECIFICAÇÕES INAMIGAS para sua funcionalidade.
  2. NÃO TESTAR ou ou se NÃO confiar em testes para detectar defeitos no software.
  3. Aplique todo o FEEDBACK de defeitos descobertos durante testes, revisões e produção a um processo e desenvolvedores que inseriram o defeito em primeiro lugar. Descarte todos os componentes defeituosos completamente assim que os defeitos forem encontrados. Atualize suas listas de verificação e treine novamente seus desenvolvedores para que eles não cometam erros assim novamente.

O teste só pode provar que você possui bugs, mas geralmente é inútil provar o contrário. Em relação ao feedback - se você tem uma máquina de fazer moedas que faz moedas e a cada 10s, em média, há um defeito. Você pode pegar a moeda, achatá-la e inseri-la novamente na máquina. A moeda que identificou o espaço em branco reciclado não será tão boa, mas talvez aceitável. cada moeda de 100 terá que ser carimbada novamente 2 vezes e assim por diante. Seria mais fácil consertar a máquina?

Infelizmente as pessoas não são máquinas. Para criar um programador bom e sem defeitos, você precisa investir muito tempo, treinando e repetindo todos os defeitos cometidos. Os desenvolvedores precisam ser treinados em métodos formais de verificação, que geralmente são difíceis de aprender e aplicar na prática. A economia do desenvolvimento de software também está trabalhando contra isso - você investiria 2 anos em treinar um programador que pode cometer menos defeitos apenas ao vê-lo saltando para outro empregador? Você pode comprar máquinas que produzem moedas perfeitas ou contratar mais 10 macacos de código para criar vários testes pelo mesmo custo. Você pode perceber esse processo exaustivo como sua "máquina", seu ativo - investir em treinamento extensivo de excelentes desenvolvedores não compensa.

Em breve, você aprenderá a desenvolver software de qualidade aceitável, mas provavelmente nunca será livre de defeitos por uma simples razão de que não há mercado para desenvolvedores que cria código perfeito porque é lento.

Alexei Polkhanov
fonte
+1 por mencionar especificações inequívocas. Sei que esse é um tópico de 2 anos, mas devo enfatizar que a sua é a única resposta para ressaltar que é incorreto supor que um bug equivale a uma falha de programação.
Brandon
0

Programa defensivamente: http://en.wikipedia.org/wiki/Defensive_programming

Se alguém seguir as convenções de programação defensiva, as alterações serão facilmente rastreáveis. Combine isso com relatórios rigorosos de erros durante o desenvolvimento e documentação sólida, como doxygen, e você poderá saber exatamente o que todo o seu código está fazendo e corrigir os erros que surgirem com muita eficiência.

Jason McCarrell
fonte
0

Isso poderia ser resultado do mal entendido de uma boa metodologia, e não apenas da capacidade genérica?

O que quero dizer é que é possível que seu chefe tenha ouvido falar em "metodologia de zero defeitos" (consulte a seção no.5) e não se deu ao trabalho de entender o que isso significava?
É claro que é inconveniente para a gerência adiar o desenvolvimento de novos recursos, em favor de erros que você não deveria ter introduzido ...
E, claro, isso ameaça o bônus dele, então é claro que você não receberá um porque "bons programadores não tem bugs "...

É bom cometer erros, desde que você possa encontrá- los e corrigi- los (dentro da razão, é claro).

Ávido
fonte
0

Um dos conceitos fundamentais do teste de software é que você NUNCA pode ter certeza absoluta de que o programa é perfeito. Você pode validá-lo para sempre, mas isso nunca prova que o programa está completo, porque rapidamente se torna inviável testar até todas as combinações de entrada / variável.

Seu chefe parece ser um daqueles que "não entende o que é tão difícil de programar, já que está apenas digitando"

SpacePrez
fonte
0

Se assumirmos que grandes empresas de software sabem como obter desenvolvedores de alto nível (como no programador de zero bugs ), podemos deduzir que o software da Microsoft deve estar sem bugs. No entanto, sabemos que isso está longe da verdade.

Eles desenvolvem seu software e, quando atingem um certo nível de bugs de baixa prioridade, simplesmente lançam o produto e os resolvem posteriormente.

A menos que você esteja desenvolvendo algo mais complexo do que uma calculadora simples, não é possível evitar erros todos juntos. Inferno, mesmo a NASA tem redundância em seus veículos e bugs também. Embora tenham testes muito rigorosos para evitar falhas catastróficas. Mas, mesmo assim, eles têm bugs no software.

Os erros são inevitáveis, assim como a natureza humana pode errar.

Não ter bugs é como ter um sistema 100% seguro. Se um sistema é 100% seguro, ele definitivamente não é mais útil (provavelmente está dentro de toneladas e toneladas de concreto e não está nem um pouco conectado à parte externa. Não é com fio nem sem fio. , não existe um sistema complexo sem erros.

Robert Koritnik
fonte
-1

Só vejo respostas sobre ser humano e propenso a errar, o que é muito verdadeiro ... mas vejo sua pergunta de outro ponto de vista.

Eu acho que você pode escrever programas sem erros, mas esses geralmente são programas que você já escreveu 10 ou 12 vezes. Na 13ª vez que você escreve o mesmo programa do zero, você já sabe como fazê-lo: conhece o problema, conhece as técnicas, conhece as bibliotecas, o idioma ... o em sua mente. Todos os padrões estão lá, em todos os níveis.

Isso acontece comigo com programas muito simples, porque eu ensino programação. Eles são simples para mim, mas difíceis para os alunos. E não estou falando de soluções para problemas que já fiz muitas e muitas vezes no quadro-negro. Claro que eu conheço isso. Quero dizer ~ programas de 300 linhas que resolvem algo usando conceitos que eu conheço muito bem (os conceitos que ensino). Escrevo esses programas sem planejamento e eles simplesmente funcionam, e sinto que conheço todos os detalhes, não preciso de TDD. Eu recebo alguns ou três erros de compilação (principalmente erros de digitação e outras coisas assim) e é isso. Eu posso fazer isso para pequenos programas e também acredito que algumas pessoas podem fazer isso para programas mais complicados. Acho que pessoas como Linus Torvalds ou Daniel J. Bernstein têm tanta clareza de mente que são as mais próximas que você pode chegar de um codificador sem erros. Se vocêsentender as coisas profundamente, acho que você pode fazê-lo. Só posso fazer isso em programas simples, como eu disse.

Minha crença é que, se você sempre tenta fazer programas que estão muito acima do seu nível (passei anos fazendo exatamente isso), ficará confuso e cometerá erros. Grandes erros como aqueles em que você repentinamente percebe que sua solução não funciona, quando finalmente entende o problema e precisa fazer alterações tão complicadas que podem impedir que você resolva o problema ou torne o código horrível. TDD é para esses casos, acredito. Você sabe que não entende o problema que está enfrentando e, portanto, faz testes em todos os lugares para garantir uma base sólida. O TDD não resolve a visão de 10.000 pés. Você pode andar em círculos com um código perfeitamente limpo o tempo todo.

No entanto, se você tentar fazer algo novo, mas que esteja um pouco acima do seu nível, poderá obter um programa perfeito ou quase perfeito. Eu acho que é realmente difícil saber quais programas estão na sua "fronteira do conhecimento", mas na teoria essa é a melhor maneira de aprender. Na verdade, eu reescrevo muitos programas do zero. Algumas pessoas precisam, mas você precisa de muito tempo e paciência, porque na terceira vez que repete um programa não trivial, não fica animado como na primeira vez.

Portanto, meu conselho é: não pense que você entende alguma coisa até poder escrever um programa sem erros apenas para isso. E tente combinar dois desses conceitos que você conhece profundamente no mesmo programa. Tenho quase certeza de que você acertará na primeira vez. Uma das melhores maneiras é reescrever software não trivial, algo que exigiu muito esforço da primeira vez (estou fazendo isso com aplicativos Android no momento). Toda vez que recomeço, troco algo ou adiciono coisas, apenas para adicionar um pouco de diversão, e posso dizer que fico melhor e melhor e melhor ... talvez não seja livre de bugs, mas realmente orgulhoso.

Pau Fernández
fonte
-1

erros de imho e artefatos de algoritmos repentinos e misteriosos devem aparecer durante o processo de codificação: eles inspiram e forçam a evolução do código.
no entanto, é possível (geralmente após alguns testes) verificar todas as variáveis ​​que podem ser usadas antes da declaração, tratar todos os erros onde quer que possam aparecer - tornar o programa zero-bug ... até que você receba uma solicitação de um recurso que foi considerado impossível quando você estava discutindo a arquitetura do programa;)

www0z0k
fonte
1
Não sei - isso parece uma espécie de abordagem mística da programação, que é um campo de ação distintamente não místico. Você não programa efetivamente por tentativa e erro ou usando uma varinha de condão. Você projeta as coisas intencionalmente. E os erros ainda aparecerão. Então você os conserta. Mas, acima de tudo, você intencionalmente cria seu código para não ter bugs.
Craig
-1

Talvez pense mais sobre a natureza dos bugs que você recebe. Se os bugs geralmente são pequenos descuidos, um foco em melhores testes e um pouco de leitura de prova de código ajudaria.

Se os erros tendem a ser devidos a decisões de programação abaixo do ideal, talvez seja necessário dedicar mais esforço a um design melhor. Nesse caso, acho que é possível depender demais dos testes para aumentar a qualidade do software, porque a aplicação de um patch em código deficiente pode tornar a manutenção futura mais complicada. Por um lado, você obtém menos erros ao encontrá-los e corrigi-los, mas, por outro lado, prepara o terreno para futuros erros.

Uma maneira de julgar se você tem um problema de supervisão ou de design pode ser considerar quanto esforço é necessário para corrigir os bugs. Se as correções tendem a ser grandes, ou você sente que não as entende bem, isso indica a figura no design do código que pode ser aprimorado.

Acho que isso se resume a uma espécie de bom gosto sobre código, que você pode desenvolver com a prática e a revisão, e lendo sobre pessoas com problemas semelhantes.

Por fim, é inútil esperar que não haja bugs, mas não há mal em tentar reduzir sua contagem de bugs, a menos que você já a tenha em algum nível baixo, e então se torna uma troca entre seu tempo e o tempo de quem encontrar erros que você não pega.

John Bickers
fonte
-2

Se você quer dizer: "zero erro ao escrever o código" -> esse é um bom objetivo, mas é praticamente impossível.

Mas se você quer dizer: "zero erro no código entregue" -> isso é possível, e eu trabalhei nesses ambientes.

Tudo o que você precisa é: qualidade de código incrivelmente alta e quase 100% de cobertura de teste (testes de unidade + testes de aceitação + testes de integração).

Na minha opinião, o melhor livro para aprender é: GOOS . Mas é claro que um livro não é suficiente. Você precisa ir a algum grupo de usuários e discutir sobre isso. Cursos, conferências, etc. A qualidade dos erros zero não é fácil.

Antes de tudo, você precisa de um chefe que esteja realmente interessado em alta qualidade e disposto a pagar por isso.

Uberto
fonte
-3

Solução do programador:

  • Pare de programar.
  • Construa um computador mecânico.
  • Substitua-o a cada 5 anos para que o desgaste mecânico não entre em jogo.

Solução do usuário:

  • Pare de usar computadores.
  • Faça tudo manualmente.
  • Sempre faça com que uma segunda pessoa verifique novamente os resultados.
rwong
fonte
-3

Concordo que, para ser um programador com zero erros, você simplesmente não pode programar / codificar. Faz parte da vida de todo programador encontrar e desenvolver bugs. Nenhum desenvolvedor experiente pode dizer, de coração, que nunca encontrou um bug em seu código.

dbramhall
fonte
-4

Emparelhe com outro engenheiro. Escreva um teste com falha. Faça com que todos os caracteres digitados sejam necessários para fazer o teste com falha. Refatore seu código para simplificá-lo. Escreva outro teste com falha e assim por diante.

Carl Coryell-Martin
fonte