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 equivocados: el punto en el que se aparta de las interpretaciones extremas de la programación defensiva es en preferir que la presencia de errores dentro de la línea de defensa del programa sea descaradamente obvia sobre el beneficio de seguridad hipotético de tolerarlos. [1] [2] Esta preferencia es también lo que justifica el uso de aserciones .
Distinguir errores
La premisa de la programación ofensiva es distinguir entre errores esperables, que provienen de fuera de la línea de defensa del programa, por improbables que sean, y errores internos prevenibles que no ocurrirán si todos sus componentes de software se comportan como se espera.
Ejemplos contrastantes:
Estrategias de detección de errores
La programación ofensiva se centra en los errores, es decir, en refutar las suposiciones del programador. Generar un mensaje de error puede ser un objetivo secundario.
Estrategias:
- Sin comprobaciones innecesarias: confiar en que los demás componentes del software se comportan como se especifica, de modo que no se oculten problemas desconocidos, es el principio básico. En particular, es posible que ya se haya garantizado que algunos errores harán que el programa se bloquee (según el lenguaje de programación o el entorno de ejecución), por ejemplo, al desreferenciar un puntero nulo . Por lo tanto, las comprobaciones de puntero nulo son innecesarias para detener el programa (pero se pueden utilizar para imprimir mensajes de error).
- Las afirmaciones (verificaciones que se pueden desactivar) son la forma preferida de comprobar cosas que no deberían ser necesarias, como los contratos de diseño entre componentes de software.
- Eliminar el código de respaldo ( modo de emergencia ) y los datos de respaldo ( 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 deba prestar especial atención a las partes no implementadas como parte de las pruebas de aceptación de fábrica , ya que el código no implementado aún no se encuentra en ninguna etapa del desarrollo impulsado por pruebas que pueda detectarse mediante pruebas unitarias fallidas .
- Eliminar 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 se ejecuta. Dado que se supone que ambos producen el mismo resultado, se puede eliminar el simplificado.
Véase también
Referencias
- ^ "Programación ofensiva". Cunningham & Cunningham, Inc. Consultado el 4 de septiembre de 2016 .
- ^ Broadwall, Johannes (25 de septiembre de 2013). "Programación ofensiva". Thinking Inside a Bigger Box . Consultado el 4 de septiembre de 2016 .
