Programação ofensiva

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

Programação ofensiva é um nome usado para o ramo da programação defensiva que se afasta expressamente dos princípios defensivos ao lidar com erros resultantes de bugs de software . Embora o nome seja uma reação a interpretações extremas de programação defensiva, os dois não estão fundamentalmente em conflito. Em vez disso, a programação ofensiva adiciona uma prioridade explícita de não tolerar erros em lugares errados: o ponto em que se afasta das interpretações extremas da programação defensiva é preferir que a presença de erros de dentro da linha de defesa do programa seja flagrantemente óbvia sobre o benefício hipotético de segurança de tolerá-los. [1] [2] Essa preferência também é o que justifica o usoafirmações .

Distinção de erros

A premissa para a programação ofensiva é distinguir entre erros esperados, vindos de fora da linha de defesa do programa, por mais improváveis, versus erros internos evitáveis ​​que não ocorrerão se todos os seus componentes de software se comportarem como esperado.

Exemplos contrastantes:

Erros esperados Erros evitáveis
Entrada de usuário inválida Argumentos de função inválidos
Esgotamento dos recursos do SO (como armazenamento, memória) Valor fora do intervalo definido (por exemplo , enum )
Falha de hardware (como rede, armazenamento) Valor de retorno não documentado ou exceção

Estratégias de detecção de bugs

A programação ofensiva está preocupada em falhar, de modo a refutar as suposições do programador. Produzir uma mensagem de erro pode ser um objetivo secundário.

Estratégias:

  • Sem verificações desnecessárias: Confiar que outros componentes de software se comportam conforme especificado, para não ocultar nenhum problema desconhecido, é o princípio básico. Em particular, alguns erros já podem ser garantidos para travar o programa (dependendo da linguagem de programação ou do ambiente em execução), por exemplo, desreferenciar um ponteiro nulo . Como tal, verificações de ponteiro nulo são desnecessárias com a finalidade de interromper o programa (mas podem ser usadas para imprimir mensagens de erro).
  • Asserções – verificações que podem ser desativadas – são a maneira preferida de verificar coisas que não deveriam ser verificadas, como contratos de design entre componentes de software.
  • Remova o código de fallback ( modo limp ) e os dados de fallback ( valores padrão ): Eles podem ocultar defeitos na implementação principal ou, do ponto de vista do usuário, ocultar o fato de que o software está funcionando abaixo do ideal. Atenção especial às peças não implementadas pode ser necessária como parte do teste de aceitação de fábrica , pois ainda o código não implementado não está em nenhum estágio do desenvolvimento orientado a teste detectável por testes de unidade com falha .
  • Remova o código de atalho (consulte o padrão de estratégia ): Um caminho de código simplificado pode ocultar bugs em um caminho de código mais genérico se o código genérico quase nunca for executado. Como os dois devem produzir o mesmo resultado, o simplificado pode ser eliminado.

Veja também

Referências

  1. ^ "Programação Ofensiva" . Cunningham & Cunningham, Inc. Recuperado em 4 de setembro de 2016 .
  2. Broadwall, Johannes (25 de setembro de 2013). "Programação ofensiva" . Pensando dentro de uma caixa maior . Recuperado em 4 de setembro de 2016 .