Meu chefe sempre me disse que um bom programador deve ser capaz de garantir que o código que ele ou ela muda é confiável, correto e completamente autocomposto; 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 de novo e de novo - mas os erros ainda estão lá.
Como posso ser um programador de bugs zero e sei o que cada caractere do meu código causará e afetará?
Não codifique nada.
Essa é a única maneira de você ser um programador de bug zero.
Os erros 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 ocorre um erro, aprender com os nossos erros e manter-se atualizado.
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 certos softwares de alto risco. O software Space Shuttle vem à minha mente. Mas sua produtividade é da ordem de algumas linhas por dia. Eu duvido que seu chefe queira isso.
This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program -- each 420,000 lines long - had just one error each. The last 11 versions of this software had a total of 17 errors.
Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specifications for that one change run 2,500 pages, a volume thicker than a phone book. The specifications for the current program fill 30 volumes and run 40,000 pages.
"Zero-bug programmer" é um oxímoro, como um cantor silencioso, mas os últimos 60 anos de programação produziram algumas dicas de sabedoria, o que fará de você um programador melhor, como:
O ponto do TDD é que você não escreve uma única linha de código se não houver um teste que requeira essa linha de código. E para levar isso 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 pepino é ideal.
A abordagem TDD dá pelo menos dois benefícios.
Ele não prova zero bugs, já que isso seria impossível (já foram apontados por inúmeras outras respostas). Mas depois de ter aprendido TDD e tornar-se bom nisso (sim, também é uma habilidade que precisa de prática), tenho uma confiança muito maior em meu próprio código, porque ele é totalmente testado. E, mais importante, posso alterar o código existente que não compreendo completamente sem me preocupar em quebrar a funcionalidade.
Mas o TDD não ajuda em nada. Você não pode escrever código livre de bugs se não entender completamente a arquitetura do sistema e as armadilhas dessa arquitetura. Por exemplo. Se você estiver escrevendo um aplicativo da Web que manipula várias solicitações simultaneamente, deve saber que não é possível compartilhar dados mutáveis entre várias solicitações (não caia na armadilha newbie para armazenar em cache dados mutáveis para melhorar o desempenho).
Acredito que as equipes de desenvolvimento que são boas no TDD entregam o código com o menor número de defeitos.
O problema é que os bugs são as 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 todos os ambientes em que seu aplicativo será executado, você realmente não pode esperar produzir 100% de código livre de erros.
Você pode reduzir a contagem de bugs por meio de muitos testes, mas, no final, provavelmente haverá algum caso secundário que não será contabilizado. Joel Spolsky escreveu um artigo particularmente interessante sobre correção de erros .
Sim, é impossível nunca ter um bug no seu código, mas não é impossível ter menos bugs. A atitude de que "Isso é burro, você sempre vai ter bugs" é apenas um policial para evitar reduzir o número de bugs no seu código. Ninguém é perfeito, mas podemos e devemos nos esforçar para sermos melhores. Em meus próprios esforços para melhorar, achei os seguintes pontos úteis.
Pessoalmente, acho que lutar pela programação livre de bugs parece ser mais caro (em tempo e dinheiro). Para chegar a zero bug, ou até mesmo perto de zero bug, você precisa ter os desenvolvedores testam completamente. Isso significa testar a regressão antes de enviar qualquer código para revisão de patch. Este modelo não me parece ser rentável. É melhor que os desenvolvedores façam testes diligentes e deixem os testes aprofundados para a equipe de QA. Aqui está o porquê:
Aceite que, quando você escrever um código, haverá bugs conectados a ele. É 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 você escrever seu último ponto e vírgula. Você ainda precisa garantir a qualidade em seu trabalho, mas você pode exagerar .
Quantas profissões você pode nomear que sempre realizam a tarefa da maneira correta na primeira vez sem revisão por pares e / ou testes?
Zero bugs? Soa como você precisa de Lisp (siga o caminho cético e evite o videoclipe).
É extraordinariamente difícil conseguir código livre de erros nos ambientes de codificação principais (Java, C #, PHP, etc.). Eu me concentraria em produzir código bem testado e revisado por pares em iterações curtas e controladas.
Manter o código tão simples quanto possível ajudará você a evitar bugs.
Certifique-se de estar usando ferramentas de análise de código (como FindBugs , PMD e assim por diante) que - combinado com avisos estritos de compilador - revelará todos os tipos de problemas com seu código. Anote o 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 pareça pouco natural codificar de uma maneira que introduza esse bug novamente.
Todos os "não codificam nada". respostas estão perdendo completamente o ponto. Além disso, seu chefe definitivamente não parece ser um idiota!
Não me lembro de quantas vezes vi programadores que simplesmente não sabiam o que o código faz. Seu único desenvolvimento philosohpy parecia ser tentativa e erro (e muitas vezes também copiar / colar / modificar). Embora tentativa e erro sejam uma maneira válida de resolver alguns problemas, muitas vezes é possível analisar o domínio do problema e, em seguida, aplicar uma solução muito específica com base no seu entendimento das ferramentas usadas e com um pouco de disciplina e diligência. apenas resolvi o problema, mas também a maioria dos casos-chave (possíveis erros) antes de você implementá-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ê encontrar ou ler, você poderá adicioná-lo às coisas que você pode querer pensar na próxima vez que escrever / alterar alguma coisa. Se você fizer isso, você ganhará muita experiência em como escrever código quase livre de bugs. - Há toneladas de recursos disponíveis sobre como se tornar um programador melhor que pode ajudá-lo na jornada ...
Pessoalmente, eu nunca iria cometer código onde não posso explicar todas as linhas. Cada linha tem um motivo para estar lá, caso contrário, deve ser removido. É claro que às vezes você fará suposições do funcionamento interno dos métodos que chama, caso contrário, você precisaria conhecer a lógica interna de toda a estrutura.
Seu chefe está completamente certo em dizer que você deve entender os resultados e o impacto do código que você escreve no sistema existente. Erros ocorrerão? Sim, claro. Mas esses bugs serão devido à sua compreensão incompleta do sistema / ferramentas com as quais você trabalha e com cada correção de bugs você terá uma melhor cobertura.
Como os outros comentários já apontaram corretamente, não há software não-trivial sem bugs.
Se você quiser testar o software, tenha sempre em mente que os testes só podem provar a presença de bugs e não 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ê quer. Escrever uma especificação completa, em quase todos os casos, também não é possível. Basicamente, ele muda o lugar onde os erros podem ocorrer da implementação para a especificação.
Então, dependendo da sua definição de "bugs", você pode tentar a verificação formal ou apenas tentar encontrar tantos bugs quanto puder no seu software.
Ou não escreva nada mais complicado que "Hello World!" ou se você disser a todos para nunca usá-lo.
Pergunte ao seu chefe alguns exemplos desse chamado código livre de bugs.
Concordo com os outros. Aqui está como eu abordaria o problema
Você pode se esforçar para ser um programador de bug zero. Eu me esforço para ser um programador de bugs zero sempre que estou escrevendo código. No entanto, eu não faço
Eu não faço essas coisas porque elas têm custo proibitivo para o software que escrevo. Se eu fizesse essas coisas, provavelmente estaria mais longe em relação a zero bugs, mas isso não faria sentido para os negócios.
Eu crio ferramentas internas que uma grande parte da nossa infraestrutura usa. Meus padrões de teste e codificação são altos. No entanto, existe um equilíbrio. Eu não espero zero bugs porque não posso ter pessoas colocando esse tipo de tempo em um único 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 jogo se meu software quebrar, então não nos envolvemos nesse nível de garantia.
Eu combinaria o nível de garantia com o uso pretendido do software. Se você está escrevendo código que o ônibus espacial da NASA usará, talvez a tolerância zero a erros seja razoável. Você só precisa adicionar um monte de práticas adicionais e muito caras.
Eu acho que um bom primeiro passo para se tornar um programador "zero-bug" é mudar sua atitude em relação aos bugs. Em vez de dizer as coisas "eles acontecem", "melhorar o controle de qualidade e os testadores" ou "os desenvolvedores são péssimos nos testes", diga:
Os erros não são aceitáveis, e farei tudo que estiver ao meu alcance para eliminá-los.
Uma vez que isso se torne sua atitude, os erros vão cair rapidamente. Em sua pesquisa para encontrar maneiras de eliminar bugs, você se deparará com o desenvolvimento orientado a testes. Você encontrará muitos livros, postagens em blogs e pessoas oferecendo aconselhamento gratuito sobre melhores técnicas. Você verá a importância de melhorar suas habilidades através da prática (como codificar katas ou tentar 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, esperamos, depois de ver que é possível escrever um bom software , sua paixão por seu ofício crescerá.
De certo modo, seu chefe está certo. É possível escrever software que se aproxima de zero bugs.
Mas o problema é que o custo de escrever (quase) programas com erro zero é proibitivamente alto . Você precisa fazer coisas como:
Use as especificações formais dos seus requisitos. Formal, como no uso de Z ou VDM ou alguma outra notação sonora matematicamente.
Use técnicas de prova de teorema para provar formalmente que seu programa implementa a especificação.
Crie amplos conjuntos de testes de unidade, regressão e sistema, para testar todos os aspectos sobre bugs. (E isso não é suficiente em si.)
Ter muitas pessoas revisando os requisitos (formais e informais), software (e provas). testes e implantações.
É extremamente improvável que seu chefe esteja preparado para pagar tudo isso ... ou aguente o tempo necessário para fazer tudo isso.
Eu obtive o status "zero bug". Eu digo aos meus usuários que é um recurso não documentado, ou eles estão pedindo um novo recurso e, portanto, é um aprimoramento. Se nenhuma dessas respostas forem aceitas, simplesmente lhes digo que não entenderam suas próprias necessidades. Assim, não há bugs. Os programadores são perfeitos.
Aqui estão os passos para criar um programa livre de bugs:
O teste só pode provar que você tem 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 cada moeda de 10s tem, em média, um defeito. Você pode pegar essa moeda, achatar e inserir na máquina novamente. moeda que fez que o branco reciclado não será tão bom, mas talvez aceitável. cada moeda de 100 terá que ser re-carimbada 2 vezes e assim por diante. Seria mais fácil consertar a máquina?
Infelizmente as pessoas não são máquinas. Para fazer um bom programador livre de defeitos, você tem que investir muito tempo, treinando e repetindo todos os defeitos feitos. 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 no treinamento de um programador que pudesse fazer menos defeitos apenas para vê-lo pular para outro empregador? Você pode comprar máquinas que fazem moedas perfeitas, ou contratar mais 10 macacos para criar um monte de testes com o mesmo custo. Você pode perceber esse processo exaustivo como sua "máquina", seu ativo - investir em treinamento extensivo de excelentes desenvolvedores não vale a pena.
Em breve, você aprenderá como desenvolver um software de qualidade aceitável, mas provavelmente você nunca será um que esteja livre de defeitos por simples razão de que não há mercado para o desenvolvedor que faz código perfeito porque é lento.
Programa defensivo: link
Se alguém seguir as convenções de programação defensivamente, as mudanças serão facilmente rastreáveis. Combine isso com relatórios de bugs rigorosos durante o desenvolvimento e documentação sólida, como com o doxygen, e você deve saber exatamente o que todo o seu código está fazendo e consertar todos os bugs que surgirem, de maneira muito eficiente.
Poderia isso ser resultado de uma má compreensão de uma metodologia boa , e não apenas de tontura genérica?
O que quero dizer é que é possível que seu chefe tenha ouvido falar de "metodologia de defeito zero" (veja a seção no.5), e não se incomodou em entender o que isso significava?
Naturalmente, é inconveniente para o gerenciamento adiar o desenvolvimento de novos recursos, em favor de bugs que você não deveria ter colocado ...
E, claro, isso ameaça seu bônus, então é claro que você não conseguirá um porque "bons programadores não têm bugs" ...
Não há problema em fazer erros, contanto que você encontre eles e conserte eles (dentro da razão, é claro).
Um dos conceitos fundamentais do teste de software é que você NUNCA pode ter absoluta certeza 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 até mesmo testar contra 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 é só digitar"
Se assumirmos que as grandes empresas de software sabem como obter os melhores desenvolvedores (como programador de bugs zero ), podemos deduzir que o software da Microsoft deve ser sem bugs. No entanto, sabemos que isso está longe da verdade.
Desenvolvem seu software e quando atingem certo nível de bugs de baixa prioridade, eles simplesmente liberam o produto e os resolvem mais tarde.
A menos que você esteja desenvolvendo algo mais complexo do que uma simples calculadora, não é possível evitar todos os erros juntos. Inferno mesmo NASA tem redundância em seus veículos e bugs também. Embora eles tenham testes muito rigorosos para evitar falhas catastróficas. Mas mesmo assim eles têm bugs em seus softwares.
Os erros são inevitáveis assim como a natureza humana erra.
Não ter bugs é como ter um sistema 100% seguro. Se um sistema é 100% seguro definitivamente não é mais útil (provavelmente está dentro de toneladas e toneladas de concreto e não está conectado ao exterior de forma alguma. Não é com fio nem sem fio. Assim como não há um sistema perfeitamente seguro , não há um sistema complexo sem erros.
Eu só vejo respostas sobre nós sermos humanos e propensos a errar, o que é muito verdadeiro ... mas eu vejo sua pergunta de outro ponto de vista.
Eu acho que você pode escrever programas sem erros, mas esses normalmente são programas que você escreveu já 10 ou 12 vezes. A 13ª vez que você escreve o mesmo programa do zero, você já sabe como fazê-lo: você conhece o problema, conhece as técnicas, conhece as bibliotecas, a linguagem ... você vê 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 tenho feito muitas e muitas vezes no quadro negro. Claro que eu sei disso. Quero dizer programas de ~ 300 linhas que resolvem algo usando conceitos que conheço muito bem (os conceitos que eu ensino). Eu escrevo estes programas sem planejamento e eles simplesmente funcionam, e eu sinto que conheço todos os detalhes, eu não preciso de TDD. Eu recebo um par 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. Eu acho que pessoas como Linus Torvalds ou Daniel J. Bernstein têm essa clareza de espírito, elas são as mais próximas que você pode chegar de um codificador sem erros. Se você entender as coisas profundamente, eu acho que você pode fazer isso. Eu só posso fazer isso por programas simples, como eu disse.
Acredito que, se você sempre tentar fazer programas que estão muito acima do seu nível (passei anos fazendo exatamente isso), você ficará confuso e cometerá erros. Grandes erros como aqueles em que você de repente percebe que sua solução não pode funcionar, quando você finalmente entende o problema e tem que fazer alterações tão complicadas que podem impedi-lo de resolver seu problema ou tornar o código horrível. O TDD é para esses casos, acredito. Você sabe que não resolve o problema que está enfrentando e, portanto, faz testes em todos os lugares para garantir que tenha uma base strong. O TDD não resolve a visão de 10.000 pés, no entanto. Você pode andar em círculos com código perfeitamente limpo o tempo todo.
No entanto, se você tentar fazer algo novo, mas apenas acima do seu nível, poderá obter um programa perfeito ou quase perfeito. Eu acho que é realmente difícil saber quais programas estão em sua "fronteira do conhecimento", mas em teoria essa é a melhor maneira de aprender. Eu reescrevo programas do zero muito, na verdade. Algumas pessoas fazem, mas você precisa de muito tempo e paciência, porque a terceira vez que você repete um programa não-trivial, você não fica excitado como da primeira vez.
Então meu conselho é: não pense que você entende alguma coisa até que você possa escrever um programa livre de bugs apenas para essa coisa. E tente combinar dois desses conceitos que você conhece profundamente no mesmo programa. Tenho quase certeza que você vai acertar da primeira vez. Uma das melhores maneiras é reescrever o software não-trivial, algo que exigiu muito esforço na primeira vez (estou fazendo isso com aplicativos Android agora). Toda vez que eu começo de novo eu mudo alguma coisa ou adiciono coisas, só para adicionar um pouco de diversão, e posso dizer que fico cada vez melhor e melhor ... talvez não seja livre de bugs, mas realmente orgulhoso.
imho bugs e artefatos de algoritmo súbitos 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 possam ser usadas antes da declaração, para lidar com cada erro onde quer que apareça - para tornar o programa zero-bug ... até que você receba uma solicitação para um recurso isso foi considerado impossível quando você estava discutindo a arquitetura do programa;)
Talvez pense mais sobre a natureza dos erros que você recebe. Se os erros são geralmente pequenos descuidos, então um foco em melhores testes e um pouco de leitura de prova de código ajudaria.
Se os bugs tendem a ser devido a decisões de programação abaixo do ideal, então, talvez seja necessário colocar mais esforço em um design melhor. Nesse caso, acho que é possível depender demais dos testes para melhorar a qualidade do software, porque aplicar um patch ao código deficiente pode tornar a manutenção futura mais complicada. Por um lado, você obtém menos bugs ao encontrá-los e consertá-los, mas, por outro lado, prepara o terreno para futuros bugs.
Uma maneira de julgar se você tem um problema com descuidos ou um problema com o design pode ser considerar o quanto de esforço é necessário para corrigir os erros. Se as correções tendem a ser grandes, ou você acha que não as entende bem, isso aponta a figura no design de código que pode ser melhorada.
Acho que se trata de uma espécie de bom gosto sobre o código, que você pode desenvolver com prática e revisão e ler sobre pessoas com problemas semelhantes.
Em última análise, é inútil esperar nenhum bug, mas não há nenhum mal em tentar reduzir a contagem de seus erros, a menos que você já o tenha em algum nível baixo, e então ele se torna um trade-off entre o seu tempo e o tempo de quem encontra erros que você não pega.Se você quer dizer: "zero erros ao escrever o código" - > esse é um objetivo legal, mas é bem impossível.
Mas se você quer dizer: "zero bugs no código entregue" - > isso é possível, e eu trabalhei em tais ambientes.
Tudo o que você precisa é: qualidade insanamente alta do código e quase 100% de cobertura de teste (testes unitários + 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 de erros 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:
Solução do usuário:
Concordo que, para ser um programador de bug zero, você simplesmente não pode programar / codificar. Faz parte da vida de todo programador encontrar e desenvolver um bug. Nenhum desenvolvedor experiente pode dizer, mão no coração, eles nunca encontraram um bug em seu código.
Emparelhe com outro engenheiro. Escreva um teste com falha. Todos os caracteres que você digitar serão necessários para fazer o teste falhar. Refatore seu código para torná-lo mais simples. Escreva outro teste falho, e assim por diante.
Tags code-quality