La programación ofensiva es un nombre utilizado para la rama de la programación defensiva que se aparta expresamente de los principios defensivos cuando se trata de errores resultantes de errores de software . Aunque el nombre es una reacción a las interpretaciones extremas de la programación defensiva, los dos no están fundamentalmente en conflicto. Más bien, la programación ofensiva agrega una prioridad explícita de no tolerar errores en lugares incorrectos: el punto en el que se aparta de las interpretaciones extremas de la programación defensiva es en preferir la presencia de errores dentro de la línea de defensa del programa para que sean descaradamente obvios sobre el beneficio hipotético de seguridad de tolerarlos. [1] [2] Esta preferencia también es lo que justifica el usoafirmaciones .
Distinguir errores
La premisa para la programación ofensiva es distinguir entre errores esperados, provenientes de fuera de la línea de defensa del programa, por improbables que sean, versus errores internos evitables que no sucederán si todos sus componentes de software se comportan como se espera.
Ejemplos contrastantes:
Errores previsibles | Errores evitables |
---|---|
Entrada de usuario no válida | Argumentos de función no válidos |
Agotamiento de los recursos del sistema operativo (como almacenamiento, memoria) | Valor fuera del rango definido (por ejemplo, enumeración ) |
Fallo de hardware (como red, almacenamiento) | Valor de retorno no documentado o excepción |
Estrategias de detección de errores
La programación ofensiva se preocupa por fallar, por lo que refutar las suposiciones del programador. Producir un mensaje de error puede ser un objetivo secundario.
Estrategias:
- Sin comprobaciones innecesarias: confiar en que otros componentes del software se comportan como se especifica, para no empapelar ningún problema desconocido, es el principio básico. En particular, es posible que ya se pueda garantizar que algunos errores bloqueen el programa (según el lenguaje de programación o el entorno de ejecución), por ejemplo, desreferenciar un puntero nulo . Como tal, las comprobaciones de puntero nulo son innecesarias para detener el programa (pero se pueden usar para imprimir mensajes de error).
- Las afirmaciones (comprobaciones que se pueden desactivar) son la forma preferida de comprobar las cosas que no deberían ser verificadas, como los contratos de diseño entre componentes de software.
- Eliminar código de reserva ( modo ineficaz ) y datos de reserva ( valores predeterminados ): estos pueden ocultar defectos en la implementación principal o, desde el punto de vista del usuario, ocultar el hecho de que el software está funcionando de manera subóptima. Es posible que se necesite una atención especial a las piezas no implementadas como parte de las pruebas de aceptación de fábrica , ya que el código aún no implementado no se encuentra en ninguna etapa de desarrollo impulsado por pruebas que se pueda descubrir mediante pruebas unitarias fallidas .
- Elimine el código de acceso directo (consulte el patrón de estrategia ): una ruta de código simplificada puede ocultar errores en una ruta de código más genérica si el código genérico casi nunca llega a ejecutarse. Dado que se supone que los dos producen el mismo resultado, se puede eliminar el simplificado.
Ver también
Referencias
- ^ "Programación ofensiva" . Cunningham y Cunningham, Inc . Consultado el 4 de septiembre de 2016 .
- ^ Broadwall, Johannes (25 de septiembre de 2013). "Programación ofensiva" . Pensando dentro de una caja más grande . Consultado el 4 de septiembre de 2016 .