PROGRAMACIÓN
TAREA 1
Tema: BAD SMELL 1: “SHOTGUN SURGERY”
Equipo: Never Surrender
Integrantes:
1. Caceres Garcia Betzabe Paulina
2. Calizaya Nogales Lizeth Veronica
3. Medrano Saavedra Jhon Antony
4. Michaga Pozo Beimar David
5. Soliz Huanco Pablo David
Docente: Torrico Bascope Rosemary
BAD SMELL 1: “SHOTGUN SURGERY”
I. DEFINICIÓN
"Shotgun Surgery" o también conocido como cirugía de escopeta es un mal olor en el desarrollo
de software que ocurre cuando un solo cambio en el código requiere hacer modificaciones en
múltiples clases o métodos dispersos en diferentes partes del sistema.
En Java, el "Shotgun Surgery"
puede ser un problema
significativo, ya que puede llevar
a una mayor complejidad,
fragilidad y dificultad para
mantener el código.
Este "bad smell" (mal olor) en el
código puede tener varios efectos
negativos:
▪ Dificultad de mantenimiento: La "shotgun surgery" dificulta la mantenibilidad del
código. Cuando un pequeño cambio provoca fallos y errores en varios lugares, por lo que
se necesita realizar modificaciones en múltiples lugares, elevando la probabilidad de que
se introduzcan errores y el tiempo de desarrollo sea mayor.
▪ Dificultad para identificar dependencias: En proyectos afectados por la "shotgun
surgery", las dependencias entre diferentes partes del código pueden ser difíciles de
identificar y gestionar. Esto puede llevar a una arquitectura confusa y a acoplamientos
innecesarios entre componentes.
▪ Incremento del riesgo de errores: La dispersión de cambios en múltiples lugares aumenta
el riesgo de errores. Es más difícil garantizar que todas las modificaciones necesarias se
realicen correctamente y se prueben exhaustivamente.
▪ Reducción de la productividad del equipo: El tiempo y los recursos necesarios para
implementar cambios aumentan con la "shotgun surgery", lo que puede reducir la
productividad del equipo de desarrollo. Los desarrolladores pasan más tiempo buscando y
modificando código en lugar de agregar nuevas funcionalidades o mejorar la calidad del
software.
II. SOLUCIÓN
La refactorización nos ayudara a eliminar el mal olor y mejorar la calidad del software. A
continuación, se presenta los siguientes casos:
Caso 1
Dispersión de lógica relacional o violación del principio de responsabilidad única: Esto sucede
cuando no se aplica el principio de responsabilidad única, por lo cual una funcionalidad especifica
esta dispersa en múltiples clases en lugar de estar centralizada en un solo lugar.
Refactorización: Podemos aplicar la refactorización aplicando:
Consolidar Funcionalidad: Identifica las partes del código que están siendo duplicadas o
modificadas juntas con frecuencia, extrae la lógica duplicada, consolida esa funcionalidad en un
solo lugar y reemplace los fragmentos y los códigos duplicados por la llamada a una nueva función.
Esto implica extraer métodos o clases para encapsular la funcionalidad relacionada.
Caso 2
Consolidar Clases Redundantes: Identifica clases que han perdido su propósito o se han vuelto
redundantes debido a la dispersión de su funcionalidad en otras clases. Mueve los atributos y
métodos de la clase redundante a la clase que ahora los utiliza, y elimina la clase original. Esto
implica integrar la lógica en una sola clase para simplificar la estructura del código y eliminar la
redundancia.
Refactorización: si mover el código a la misma clase dejas las clases originales casi vacías, intente
deshacerse de estas clases ahora redundantes a través de Inline Class.
III. EJEMPLOS
Caso 1:
Este caso es dispersión de lógica relacional, donde la funcionalidad esta dispersa en varias partes
del código.
EJEMPLO 1:
En este ejemplo, la lógica para calcular el salario neto está dispersa en varias clases
(CalculadoraImpuestos, CalculadoraBonos, y GestorNominas). Esto hace que si necesitamos
cambiar la forma en que se calcula el salario neto, tendríamos que modificar múltiples clases.
Dispersión de la lógica
relacional
Dispersión de la lógica
relacional
Código refactorizado: Para solucionar este problema, podemos centralizar la lógica del cálculo
del salario neto en una sola clase, por ejemplo, CalculadoraSalarioNeto.
La lógica para calcular el salario neto ahora está centralizada en la clase CalculadoraSalarioNeto.
Esto hace que sea más fácil de mantener y modificar.
La clase CalculadoraSalarioNeto tiene una única responsabilidad: calcular el salario neto. Las
clases CalculadoraImpuestos y CalculadoraBonos también tienen responsabilidades únicas, lo que
facilita la comprensión y el mantenimiento del código. Ahora, si necesitaríamos a un futuro
cambiar la forma en que se calcula el salario neto, solo necesitaríamos modificar la
clase CalculadoraSalarioNeto.
Caso 2
Imaginemos que estamos modelando un sistema simple para gestionar información sobre
departamentos y ciudades de Bolivia. Inicialmente, tenemos dos clases: Departamento y Ciudad.
EJEMPLO 2:
La clase Ciudad ahora solo contiene atributos y métodos simples que podrían estar directamente
en la clase Departamento. Esto hace que Ciudad sea redundante.
Clases redundantes
Código Refactorizado: Para solucionar el problema, vamos a eliminar la clase Ciudad y mover
sus atributos y métodos directamente a la clase Departamento.
Teníamos dos clases (Departamento y Ciudad), pero Ciudad se volvió redundante después de
mover su funcionalidad a Departamento. Aplicamos Inline Class para eliminar la clase Ciudad y
mover sus atributos y métodos directamente a Departamento. Simplificamos el código y
eliminamos la redundancia.
Referencias bibliográficas
Das, A. (6 de abril de 2024). Shotgun Surgery Code Smell: Examples & Refactoring Guide. Bito.
Recuperado de https://bito.ai/blog/eliminating-shotgun-surgery/
Fowler, M. (2019). Refactoring Improving the design of existing code. Pearson.
Ndepend. (2 de octubre de 2018). Shotgun Surgery: What is an how to stop it. Recuperado de
https://blog.ndepend.com/shotgun-surgery/
