Como ser um programador de erro zero? [fechadas]

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á?

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.

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.

"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!

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.

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 .

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.

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?

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.

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.

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.

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.

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.

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.

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á.

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.

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.

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.

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.

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).

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"

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.

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 vê 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.

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;)

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.

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.

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.

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.

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.