La cirugía de escopeta es un antipatrón en el desarrollo de software y ocurre cuando un desarrollador agrega características al código base de una aplicación que abarca una multiplicidad de implementadores o implementaciones en un solo cambio. Esta es una práctica común en muchos escenarios de programación, ya que generalmente se invierte una gran cantidad de esfuerzo de programación en agregar nuevas funciones para aumentar el valor de los activos de programación. Como consecuencia, estas nuevas características pueden requerir agregar código en varios lugares simultáneamente donde el código en sí se ve muy similar y solo puede tener ligeras variaciones. Debido a la naturaleza acelerada del desarrollo de software comercial, es posible que no haya tiempo suficiente para remodelar (o refactorizar) un sistema para admitir las nuevas funciones de manera trivial. Como consecuencia, prevalece la práctica de la codificación de cortar y pegar ; el código se escribe en un solo lugar y luego simplemente se copia en todos los demás lugares donde se requiere esa implementación (con los cambios necesarios aplicados en el lugar).
Esta práctica es generalmente mal vista por la comunidad de refactorización como una violación directa del principio Once and Only Once ; en última instancia, cualquier cambio en la nueva funcionalidad puede requerir cambios generalizados. Además, cualquier error de software potencial en esta nueva función se replicará muchas veces y puede hacer que la corrección de errores sea particularmente difícil y tediosa. Incluso en ausencia de código copiado, se garantiza que las implementaciones serán muy similares e igualmente propensas a cambios de requisitos o corrección de errores. Esta forma de desarrollo de software tiende a favorecer la mejora a corto plazo (en forma de características adicionales) a costa de la mantenibilidad y estabilidad a largo plazo.
Ejemplo
El ejemplo canónico de esta práctica es el registro, que generalmente agrega código de prólogo a muchas funciones simultáneamente, por ejemplo:
void MyFunc () { ... }void MyFunc2 () { ... }...void MyFuncN () { ... }
Podría transformarse en:
void MyFunc () { printf ( "Ingresando a MyFunc \ n " ); ... }void MyFunc2 () { printf ( "Ingresando a MyFunc2 \ n " ); ... }...void MyFuncN () { printf ( "Ingresando a MyFuncN \ n " ); ... }
Aquí, un solo requisito ha agregado código similar a varias funciones simultáneamente. Como tal, cualquier cambio en los requisitos aquí (es decir, agregar números de línea al registro) ahora requeriría un esfuerzo considerable. La cirugía de escopeta no es sinónimo de cortar y pegar codificación, como lo destaca este ejemplo trivial. La práctica de copiar código puede verse como un "medio para un fin", donde la cirugía de escopeta es simplemente un "fin" (es decir, hay muchas formas de llegar a la misma conclusión).
Consecuencias de la cirugía de escopeta
Las preocupaciones con este estilo son en general las mismas que las de cualquier duplicación en un sistema de software; es decir, duplicar la misma lógica en muchos lugares puede aumentar enormemente los costos de realizar cambios en la misma lógica más adelante. Algunos de los costos antes mencionados son mensurables, otros no (al menos no trivialmente). También hay alguna evidencia de que este antipatrón se correlaciona con tasas más altas de defectos. [1]
Por lo general, se espera alguna combinación de lo siguiente:
- Mayor esfuerzo del desarrollador y menor rendimiento
- Costo monetario asociado de lo anterior (como en desarrollo comercial)
- Efectos psicológicos y posible negligencia del código
De estos, los más insidiosos son los efectos psicológicos (por ejemplo, ver Teoría de las ventanas rotas ) que pueden conducir exponencialmente a la descomposición del software . [ cita requerida ] Cuando no se controla, esto puede hacer que bases de código completas no se puedan mantener. Generalmente, la única solución a este problema es reescribir completamente el código [ cita requerida ] (a un costo sustancial).
Mitigación
La programación orientada a aspectos (AOP) tiene como objetivo reducir estas formas de modificaciones invasivas a favor de la adopción de un "aspecto" o "preocupación". Las soluciones toman la forma de código repetitivo que se puede aplicar sobre un dominio de funciones simultáneamente (a través del proceso de tejido ), lo que reduce enormemente la cantidad de código duplicado. El uso de lenguajes específicos de dominio también se está generalizando donde se escriben compiladores livianos para generar la mayor parte del código duplicado en nombre del programador. Ambos métodos se incluyen en las categorías más amplias de generación y automatización de código .
Ver también
- Depuración de escopeta
- Deuda técnica
- Viscosidad , una medida de resistencia al cambio para el diseño de notaciones .
Referencias
- ^ "Una investigación de los malos olores en el diseño orientado a objetos - publicación de la conferencia IEEE". doi : 10.1109 / ITNG.2006.31 . S2CID 13107711 . Cite journal requiere
|journal=
( ayuda )