O que você considera ser a principal causa de defeitos de software (e como minimizá-los) [closed]

14

Eu defino defeito como:

"something within the application design or code which prevents it functioning as per requirements."

Estou à procura de ideias sobre as causas dos defeitos, por exemplo, o fator humano, a falta de testes, a falta de protótipos e possíveis ideias para mitigá-los.

    
por Chris Buckett 20.09.2010 / 13:25
fonte

17 respostas

13

A principal causa dos defeitos de software é a interpretação.

A interpretação do cliente de um recurso difere da interpretação do designer.

A interpretação do designer difere da interpretação do programador.

A maioria das metodologias inventou maneiras de combater esse efeito. Mas no final, somos apenas humanos e não somos perfeitos. Além disso, muitas vezes há uma pressão de tempo e a maioria das metodologias mágicas é frequentemente omitida sob pressão.

O teste só pode detectar os problemas no início. Mas até os testadores são humanos, e é impossível testar 100%. Se você quiser liberar antes que o universo termine.

    
por 20.09.2010 / 13:33
fonte
8

Eu considero a principal causa dos defeitos de software serem programadores.

Não dizer que apenas seja engraçado, mas porque um dos grandes problemas que observei no meu trabalho é a falta de coleta de requisitos, juntamente com uma compreensão insuficiente do domínio do problema, causando grandes defeitos e problemas de usabilidade no projeto.

Parte disso vem de não estar disposto a aprender / entender a terminologia do usuário final, causando mal-entendidos.

Parte disso vem de falar de tecnologia muito cedo no processo para pessoas que não têm ideia do que você está falando ou por que isso é importante.

O melhor exemplo disso foi quando ouvi um dos programadores tentando descobrir quanto tempo as perguntas / respostas estariam em caracteres ... Eu sabia que ele estava tentando descobrir qual campo de tamanho usar no banco de dados , mas o departamento que solicitava isso não tinha a menor dúvida de que isso importava - ou que os espaços contavam. Para nós isso parece óbvio, mas para eles foi uma verdadeira revelação.

    
por 20.09.2010 / 13:34
fonte
8

A principal causa de defeitos é gerenciamento incorreto ;)

Sério, um desenvolvedor que trabalha em boas condições, que não precisa trabalhar demais, ter qualidade, ter ferramentas adequadas, condições de trabalho silenciosas e assim por diante produzirá menos bugs do que alguém trabalhando sob strong pressão.

Além disso, o gerenciamento da contratação de desenvolvedores ruins também ajuda a aumentar o número de bugs.

Gerenciamento incorreto .

(disclaimer: eu devo contratar e gerenciar desenvolvedores)

    
por 20.09.2010 / 13:42
fonte
5

Eu não vejo nenhuma causa primária - mas uma causa que não foi mencionada é o acoplamento não intencional com outro código . Escrever código que tem efeitos colaterais invisíveis, rompe camadas de abstração, faz suposições sobre dados (variáveis não são, constantes não são, e nenhuma entrada de um usuário é segura), mucks com coisas que não precisam se preocupar com, e assim por diante.

A maioria das práticas de desenvolvimento que eu estudo se resumem a reduzir N , porque a complexidade de um programa é de pelo menos O(N^2) e possivelmente O(k^N) . Definir N é deixado como um exercício para o leitor, mas estou pensando em coisas como complexidade ciclomática aqui. O encapsulamento da lógica e dos dados tem o efeito de reduzir o N ao compartimentar o problema.

    
por 30.09.2010 / 21:50
fonte
4

A incapacidade de pensar em tudo.

    
por 30.09.2010 / 21:57
fonte
4

Sendo incompleto

    
por 12.10.2010 / 16:06
fonte
4

Lacuna de comunicação. Na coleta de requisitos. No horário. No documento de design. Na especificação funcional. No código (lacuna entre o que o programador quer e o que ele diz ao compilador).

Etiqueta social. É socialmente inaceitável chamar alguém de alguém incapaz.

    
por 12.10.2010 / 22:01
fonte
3

Correndo para as coisas sem entendê-las completamente. Começando a escrever código sem entender completamente os requisitos funcionais ou a arquitetura técnica.

A programação deve ser quase automática, apenas anotando aquilo que é auto-evidente e já foi elaborado na mente. Na prática, vejo muitos problemas no código para tentar entender exatamente o que o código deve fazer. Eu já fui culpado disso muitas vezes.

    
por 12.10.2010 / 20:19
fonte
2

Errare humanum est

    
por 12.10.2010 / 15:16
fonte
2

Pressão de programação é certianamente uma fonte strong.

Os desenvolvedores apressados não dedicam tempo para especificar totalmente os requisitos ou entender completamente a intenção por trás dos requisitos, ou investigar totalmente as alternativas para encontrar a melhor solução, ou pensar completamente em todos os casos e interações das alterações que eles são criar ou desenvolver um conjunto completo de casos de teste ou executar totalmente o teste de unidade ou executar um teste de integração completo ou considerar totalmente as dependências da plataforma ou testar totalmente o instalador ou documentar completamente o que eles fizeram na próxima desenvolvedor pode entender ....

    
por 12.10.2010 / 18:47
fonte
2

Outra coisa que deve ser mencionada é não ter um teste externo. Quando o desenvolvedor escreve os testes e os executa, ele apenas testa sua interpretação e não o requisito real. Embora o teste de unidade escrito pelos desenvolvedores seja útil para detectar alguns bugs, a maioria dos bugs passou nesses testes, mas não é o que o usuário quer ou precisa. Qualquer software que não tenha sido testado por alguém que não seja o desenvolvedor não foi testado (e não quero dizer apenas executar os testes do desenvolvedor).

    
por 12.10.2010 / 20:03
fonte
2

É porque a engenharia de software é inerentemente complexa. O ensaio "No Silver Bullet" discute isso.

Ironicamente, muitas das outras respostas aqui tocam em tópicos que são "acidentalmente complexos", na linguagem daquele ensaio, enquanto que, na realidade, a maioria dos desenvolvedores de software é "essencialmente complexa", então é apenas da natureza de que criar software é difícil, software terá bugs e nosso trabalho é lidar com isso.

    
por 12.10.2010 / 21:32
fonte
1

A incapacidade de entender o software como uma rede de máquinas de estado, os princípios subjacentes à sua operação (estados, sua determinação e transições) e as interações das máquinas de estado.

    
por 12.10.2010 / 13:19
fonte
1

Escrevendo código que falha silenciosamente versus código que relata todos os erros.

    
por 20.10.2010 / 15:34
fonte
1

A falta de verificação de coisas que "não podem acontecer" ou que provavelmente não acontecerá é grande. Às vezes o perfeito é o inimigo do bem. Se não vale a pena uma hierarquia de exceções bem pensada, alguma manipulação rápida e suja é sempre melhor que nada. Sou um enorme fã de falhas rápidas, de afirmações e de deixar declarações que têm um impacto insignificante sobre o desempenho nas versões de lançamento. Mesmo em scripts únicos rápidos e sujos, onde controlo todos os dados de entrada, coloco alguns erros rápidos / sujos na manipulação, normalmente apenas com uma função que é equivalente a afirmar, mas permanece ligada o tempo todo. Minha regra é que, se não é provável que ocorra ou você acha que não pode acontecer, não precisa falhar normalmente com uma mensagem de erro amigável, mas deve pelo menos falhar rápido com uma mensagem de erro que dá ao programador algumas dicas sobre o que deu errado.

Editar: Uma tática útil relacionada é usar as afirmações como uma ferramenta de depuração principal e deixá-las lá após a conclusão da sessão de depuração. Daquele ponto em diante, sua base de código terá algumas verificações de integridade que tornam muito difícil que erros relacionados aconteçam novamente. Isso é especialmente útil para códigos difíceis de serem testados.

    
por 20.10.2010 / 18:31
fonte
1

A principal causa dos defeitos de software é escrever código.

Escreva menos código e você terá menos bugs; -)

    
por 28.10.2010 / 21:19
fonte
0

Em um nível, gerenciamento. Mas não é só o PHB. É o gerenciamento do próprio código, que pode ou não ser um reflexo do gerenciamento corporativo.

Os participantes em todo o "ciclo de vida" precisam ser totalmente investidos em qualidade e fazer um produto que simplesmente não morra . O software em si tem a promessa de nunca quebrar, dada a confiabilidade adequada da abstração. É apenas uma questão de saber se os construtores de software estão interessados em ter essa operação perfeita.

    
por 20.10.2010 / 18:16
fonte