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

Eu defino defeito como:

"algo dentro do design ou código do aplicativo que o impede de funcionar conforme os requisitos."

Estou procurando idéias sobre as causas dos defeitos, por exemplo, o fator humano, falta de teste, falta de prototipagem e possíveis idéias para atenuá-las.

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

A interpretação de um recurso pelo cliente 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 magias de metodologia é frequentemente ignorada sob pressão.

Os testes podem detectar apenas os problemas mais cedo. Mas mesmo os testadores são humanos e é impossível testar 100%. Se você quer liberar antes que o universo termine.

Considero a principal causa de defeitos de software os programadores.

Não estou dizendo isso apenas para ser engraçado, mas porque um dos grandes problemas que observei no meu trabalho é a falta de coleta de requisitos, juntamente com o fraco entendimento 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 sobre tecnologia muito cedo no processo para pessoas que não têm idéia do que você está falando ou por que isso importa.

O melhor exemplo disso foi quando ouvi um dos programadores tentando descobrir quanto tempo as perguntas / respostas durariam nos caracteres ... Eu sabia que ele estava tentando descobrir qual tamanho de campo usar no banco de dados, mas o departamento solicitando isso não era o mais nebuloso porque isso importava - ou que os espaços contavam. Para nós isso parece óbvio, mas para eles foi uma revelação real.

A principal causa de defeitos é uma má gestão ;)

Sério, um desenvolvedor que trabalha em boas condições, que não é obrigado a trabalhar demais, reduzir a qualidade, ter ferramentas adequadas, condições de trabalho silenciosas etc.

Além disso, a gerência que contrata desenvolvedores ruins também ajuda a aumentar o número de bugs.

Má gestão .

(aviso: devo contratar e gerenciar desenvolvedores)

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 com efeitos colaterais invisíveis, rompe as camadas de abstração, faz suposições sobre os dados (variáveis ​​não, constantes não e nenhuma entrada de um usuário é segura), mexe com coisas que não precisam preocupar com ele e assim por diante.

A maioria das práticas de desenvolvimento que eu estudo se resume à redução N, porque a complexidade de um programa é pelo menos O(N^2)e possivelmente O(k^N). A definição Né deixada como um exercício para o leitor, mas estou pensando em coisas como complexidade ciclomática aqui. Encapsular lógica e dados tem o efeito de reduzir N compartimentalizando o problema.

A incapacidade de pensar em tudo.

Sendo incompleto

Lacuna de comunicação. Na coleta de requisitos. Dentro do cronograma. No documento de design. Na especificação funcional. Em código (intervalo entre o que o programador deseja e o que ele diz ao compilador).

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

Apressando-se nas 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 o que é evidente e que já foi trabalhado na mente. Na prática, vejo muitas falhas no código para tentar entender exatamente o que o código deve fazer. Eu já fui culpado disso muitas vezes.

Errare humanum est

A pressão de programação é certianly uma fonte forte.

Os desenvolvedores apressados ​​não reservam tempo para especificar completamente os requisitos, nem entender completamente a intenção por trás dos requisitos, nem investigar completamente as alternativas para encontrar a melhor solução, nem pensar completamente em todos os casos extremos e interações das alterações que estão fazendo, ou desenvolva um conjunto completo de casos de teste, ou execute todo o teste de unidade, ou execute um teste de integração completo, ou considere totalmente as dependências da plataforma, ou teste completamente o instalador, ou documente completamente o que eles fizeram para que o próximo desenvolvedor possa entender ....

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, não o requisito real. Embora o teste de unidade escrito pelos desenvolvedores seja útil para detectar alguns erros, a maioria dos erros passou nesses testes, mas não é o que o usuário deseja ou precisa. Qualquer software não testado por alguém que não seja o desenvolvedor não é testado (e não quero dizer apenas executar os testes do desenvolvedor).

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

Ironicamente, muitas das outras respostas aqui abordam tópicos que são "acidentalmente complexos", na linguagem desse ensaio, enquanto, na realidade, a maior parte do que os desenvolvedores de software fazem é "essencialmente complexo", por isso é apenas da natureza disso que criar o software é difícil, o software terá bugs e nosso trabalho é lidar com isso.

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

Escrever código que falha silenciosamente vs. código que relata todos os erros.

A falta de verificação de coisas que "não podem acontecer" ou que dificilmente acontecem é grande. Às vezes o perfeito é o inimigo do bem. Se não vale uma hierarquia de exceção bem pensada, um tratamento rápido e sujo é sempre melhor que nada. Eu sou um enormefã de falhar rápido, de afirmações e de deixar afirmações que têm um impacto insignificante no desempenho em versões de lançamento. Mesmo em scripts únicos rápidos e sujos, onde eu controle todos os dados de entrada, insiro algum tratamento de erro rápido / sujo, geralmente apenas com uma função que é equivalente a afirmar, mas permanece ativa o tempo todo. Minha regra geral é 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 rapidamente com uma mensagem de erro que dá ao programador algumas dicas sobre o que deu errado.

Editar: Uma tática útil relacionada é usar asserts como a principal ferramenta de depuração e deixá-los lá depois que a sessão de depuração terminar. A partir desse momento, sua base de código terá algumas verificações internas de integridade que dificultam a ocorrência de erros relacionados. Isso é especialmente útil para códigos difíceis de unittest.

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

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

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

Os participantes de todo o "ciclo de vida" precisam ser totalmente investidos em qualidade e criar um produto que simplesmente não morra . O próprio software 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.