Desarrollo de software. ¿Es la reducción de la deuda técnica una estrategia de programación defensiva?

Hay opiniones para todos los gustos. Una de la más extendida es que son conceptos distintos y que no tienen influencia uno sobre otro.

Yo soy de la opinión de que expresando cosas distintas son compatibles y por tanto sí que existe esa influencia.

En la programación defensiva trato de proteger secciones del producto de la volatilidad de las funcionalidades y de los errores del usuario (especificaciones incorrectas) y propios (efectos colaterales, especificaciones que no se han terminado de comprender bien, etc…).

¿Dónde entra en juego la deuda técnica? En el momento en que hay que seguir evolucionando el software (o realizar correcciones), con una deuda técnica por encima de la que el producto debería tener, el esfuerzo es mucho mayor y tardamos más en dar una respuesta. En ocasiones si el cambio es importante y la deuda técnica alta, el desarrollador se encuentra con un problema muy serio.

Una deuda técnica baja (o al menos proporcional a las características del producto y del contexto en que se ha desarrollado) nos permite reaccionar mejor al cambio (sea cual sea su origen) por lo que tener en cuenta esta características supone, al menos para mi, una importante estrategia de programación defensiva (de hecho hay parámetros que se utilizan para medir la deuda técnica como es la cobertura mediante pruebas unitarias que suponen técnicas directas de programación defensiva).

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: