Shotgun Surgery, o 'cirugía de escopeta', es un anti-patrón de diseño de software que se manifiesta cuando la implementación de un cambio o la adición de una nueva característica a un sistema exige modificaciones en un gran número de clases o módulos pequeños y distribuidos. En lugar de encapsular la lógica relacionada en un solo lugar, la responsabilidad se encuentra fragmentada, lo que resulta en una dispersión de cambios cada vez que la funcionalidad subyacente evoluciona. Este 'code smell' es un síntoma de baja cohesión y alto acoplamiento, violando principios como el Single Responsibility Principle (SRP) y el principio de encapsulación.
Este anti-patrón es común en sistemas monolíticos con arquitecturas pobremente diseñadas o que han sufrido un crecimiento orgánico sin refactorización adecuada. Por ejemplo, en una aplicación empresarial, si la adición de un nuevo tipo de cliente o la modificación de una regla de negocio de facturación requiere tocar clases en el módulo de autenticación, el de persistencia de datos, el de interfaz de usuario y el de generación de informes, se está incurriendo en Shotgun Surgery. Aunque no es una herramienta o sistema en sí mismo, su presencia es un indicador de problemas estructurales en el código base de cualquier sistema, desde microservicios mal diseñados hasta grandes frameworks como Spring o .NET si no se aplican buenas prácticas de diseño.
Para un Arquitecto de Sistemas, la presencia de Shotgun Surgery es una señal de alerta crítica. Implica que el sistema es frágil, costoso de mantener y propenso a errores, ya que cada cambio aumenta el riesgo de introducir regresiones en múltiples puntos. La corrección de este problema a menudo implica refactorizar el código para aumentar la cohesión y reducir el acoplamiento, aplicando patrones como Strategy, Template Method o Visitor, o consolidando la lógica dispersa en clases o servicios más responsables. Ignorar Shotgun Surgery conduce a un Technical Debt creciente, ralentiza la velocidad de desarrollo, dificulta la escalabilidad y la evolución del sistema, y puede ser un factor determinante en la decisión de re-arquitecturar o reescribir componentes críticos.