M.C. Juan Carlos Olivares Rojas

Presentación del tema: "M.C. Juan Carlos Olivares Rojas"— Transcripción de la presentación:

1 M.C. Juan Carlos Olivares Rojas
“Bad Smells” en código M.C. Juan Carlos Olivares Rojas Febrero 2011

2 Agenda Código Duplicado Métodos grandes Clases grandes
Lista de Parámetros excesiva Características de la “envidia” Skype: juancarlosolivares Web:

3 Agenda Sentencias Switch Jerarquías de Herencia Paralelas
Campos Temporales Encadenamientos de mensajes Skype: juancarlosolivares Web:

4 Agenda Clases alternativas con diferentes interfaces
Librerías de clases incompletas Skype: juancarlosolivares Web:

5 Competencia Específica
aprenderá e identificará los malos hábitos de codificación (bad smells), conociendo así los errores que generalmente se cometen al desarrollar código. Competencia Específica Nos auxiliamos de muchas competencias genéricas (ver programa de la materia) Genéricas Instrumentales: Capacidad de análisis y síntesis, Solución de problemas, Toma de decisiones. Interpersonales: Capacidad crítica y autocrítica, Capacidad de trabajar en equipo interdisciplinario, Habilidad para trabajar en un ambiente laboral, Compromiso ético. Sistémicas: Capacidad de aprender, Capacidad de adaptarse a nuevas situaciones, Capacidad de generar nuevas ideas (creatividad), Habilidad para trabajar en forma autónoma, Preocupación por la calidad.

6 Criterios de Evaluación
70% Examen práctico 30% Desarrollo de portafolio de evidencias (trabajos, tareas y prácticas)

7 Código Duplicado

8 Un “bad smell” es una mala práctica de programación que debe de ser eliminada para que el código sea más legible y por ende más mantenible. Los refactoring funcionan como desodorante permitiendo que sea mejor la programación. Bad Smells

9 Badsmell Si algo huele mal… Muy probablemente este mal.
La codificación deficiente trae consigo una serie de características que la evidencian rápidamente. Badsmell Mito: Los programadores de antes eran mejores

10 Los “malos olores” son visto como signos de debilidad del código.
En general, para cada “mal olor” existe una serie de refactorings propuesto para solucionarlos. Badsmell Mito: Los programadores de antes eran mejores

11 REFACTORING PROPUESTO
Malos Olores BAD SMELL REFACTORING PROPUESTO CODIGO DUPLICADO EXTRAER EL MÉTODO SUBIR VARIABLES SUSTITUIR EL ALGORITMO MÉTODOS LARGOS INTRODUCIR OBJETOS COMO PARÁMETROS REEMPLAZAR EL MÉTODO CON UN OBJETO MÉTODO CLASES GRANDES EXTRAER CLASES EXTRAER SUBCLASES CARACTERÍSTICA DE LA “ENVIDIA” MOVER MÉTODO CLASES “PEREZOSAS” COLAPSAR JERARQUÍAS

12 Código Duplicado Es el principal indicador de un malor olor.
¿cómo detectamos código duplicado? Código Duplicado

13 Código Duplicado Misma expresión en dos métodos de la misma clase.
Misma expresión en dos subclases hermanas. Códigos que sean similares, pero no iguales. Código Duplicado

14 Código Duplicado Métodos que hagan lo mismo con diferente algoritmo.
Duplicidad de código en dos clases independientes. La gran mayoría de los “Bad Smells” se da por la “codificación excesiva” Código Duplicado

15 La codificación excesiva se da por muchas razones: malos hábitos de programación, presión del tiempo de desarrollo, etc. La decisión de reestructurar código depende de los desarrolladores. Código Duplicado

16 Aunque no está enfocado directamente con la codificación, es el principal mal olor en la implementación del software. Generalmente no se hace diseño y cuando llega a hacerse se hace muy superficial sólo por cumplir el requerimiento. Mal Diseño

17 En un diagrama de clases en UML es posible verificar algunos indicadores de malos olores y poder reestructurarlos antes de codificarlos. Mal Diseño

18 Existirán indicadores que no son muy visibles en el modelado como los métodos largos o el código duplicado. Se pueden utilizar otros diagramas de UML como los de secuencia, actividades, estados, etc. Mal Diseño

19 Práctica 3

20 TDD (Test-Driven Development) es una metodología de diseño la cual consiste en codificar en principio las pruebas unitarias del código. Se diseñan todos los posibles casos de prueba y se verifican sus resultados.  Práctica 3

21 Se codifican las pruebas unitarias y hasta que no se pasen al 100% el programa no puede terminar.
Nótese que al inicio las pruebas no pueden correrse hasta que se ejecute el código.  Práctica 3

22 Los malos olores también pueden ser determinados a través de herramientas automatizadas, generalmente conocidos como analizadores de códigos. Una herramienta popular es PMD que puede analizar código escrito en Java Código Duplicado

23 ¿Si se codifica bien desde el principio no se tendría que reestructurar el software?
Sólo serían muchos menores los cambios La solución para el buen desarrollo de software son los patrones de diseño. Patrones de Diseño

24 Es una solución bien documentada que los expertos aplican para solucionar nuevos problemas porque han sido utilizadas con éxito en el pasado. Patrones de Diseño

25 Los patrones suponen una evolución en abstracción y reutilización del software.
Los patrones de diseño están basados en esquemas que funcionan. ¿Cómo es una casa estilo americano? Patrones de Diseño

26 Realizar un programa que permita que un momento dado uno y solo un objeto pueda estar en ejecución (no se permiten dos o más ejemplares). La utilización de patrones puede resolver este problema. Caso de ejemplo: Singleton Patrones de Diseño Algunas APIs están implementadas bajo patrones de diseño. Por ejemplo algunos tipos de ventana en Swing.

27 Problema: se admite exactamente una instancia de una clase
Problema: se admite exactamente una instancia de una clase. Los objetos necesitan un único punto de acceso global. Solución: Defina un método estático de la clase que devuelva el Singleton Singleton

28 Singleton

29 Singleton public class Singleton { private static Singleton INSTANCE = null; private Singleton() {} private synchronized static void createInstance() { if (INSTANCE == null){ INSTANCE = new Singleton(); }

30 Patrón de Diseño de un Menú

31 Actividad Realizar el análisis del programa Criba cn la herramienta PMD a nivel máximo y tratar de minimizar la mayor cantidad de errores posibles

32 Actividad Modificar el patrón singleton para que permita que un objeto se pueda crear un número específico de veces (por ejemplo de 3 a 5) ¿Cómo quedaría dicho patrón? Tarea: traer un programa con orientación a objetos de más de 200 LOC. Mañana por antes de las 13:00 horas.

33 Métodos Grandes

34 El tener métodos grandes trae consigo muchas consecuencias como el hecho de que es menos reusable y más dificil de leer. Se recomienda que los métodos no sean mayores a 24 líneas Métodos grandes

35 El número de líneas puede ser variable pero se recomienda que se pueda leer en una sola pantalla.
Es deseable que los métodos no sea tan cortos para evitar el seguir el flujo del programa El éxito en la programación es el equilibrio. Ni mucho ni poco Métodos grandes

36 Extract Method es el refactoring más popular para malos olores como código duplicado y métodos grandes (casi el 99% de la solución es este refactoring) Extract Method

37 El nuevo método que se ha extraído contiene el código seleccionado y el código seleccionado del miembro existente, se reemplaza por una llamada al nuevo método. Extract Method

38 Extract Method

39 Clases Grandes

40 Clases Grandes En la gran mayoría de las ocasiones, una clase grande es sinónimo de código duplicado o que la clase está realizando más acciones de las debidas. ¿cómo sabemos que una clase es grande?

41 Clases Grandes Las clases no son grandes por el tamaño de su código ni por su número de elementos. Se debe verificar que la clase realice solo las acciones necesarias. Por ejemplo que no mezcle E/S con la lógica de la aplicación.

42 Antipatrones de Diseño
Antipatrón es un patrón de diseño que invariablemente conduce a una mala solución para un problema. Al documentarse tanto los antipatrones como los patrones de diseño, sirven de base para no escoger malos caminos, partiendo de documentación disponible en lugar de simplemente la intuición.

43 Antipatrón BLOB Mejor conocido como “objeto todopoderoso”. Se presenta cuando una clase es muy grande tanto en atributos y/o en métodos.

44 Antipatrón BLOB Entre más grande son las clases es más difíciles de mantener, reusar y probar. Su gran tamaño puede perjudicar el tiempo de carga. Generalmente son el resultado de un mal diseño o de sistemas legados.

45 Antipatrón BLOB

46 Antipatrón BLOB

47 Antipatrón BLOB

48 Antipatrón BLOB Algunos autores consideran al Singleton (Simplicidad) un ejemplo de un antipatrón ¿por que?

49 Antipatrón BLOB Dificulta las pruebas de código ya que promueve un alto acoplamiento. La clase controla su propia creación cuando esta no debe de ser su responsabilidad.

50 Antipatrón BLOB Se recomienda utilizar el patrón de diseño Factory para crear objetos. En general su naturaleza estática y pública no son del todo bien vistas.

51 Lista de Parámetros excesiva

52 Lista de Parámetros excesiva
El manejo de parámetros de forma excesiva es una mala práctica de programación ya que implica el paso de muchos parámetros difíciles de recordar. No hay una métrica exacta para el número de parámetros Lista de Parámetros excesiva

53 Lista de Parámetros excesiva
Nuestra recomendación será manejar hasta 4 parámetros como máximo. Si se supera del límite establecido se deberá reestructurar. Lista de Parámetros excesiva

54 Lista de Parámetros excesiva
Se pueden elegir otras métricas como que el ancho del código no rebase 80 caracteres o bien una sola pantalla de texto. Se debe hacer uso de las bondades del lenguaje como el polimorfismo y el uso de parámetros predeterminados. Lista de Parámetros excesiva

55 Lista de Parámetros excesiva
En general se debe de reestructurar el número de parámetros por la utilización de estructuras como arreglos y/o objetos. Se recomienda utilizar refactroings como: Replace parameters with method e Introduce parametrs with object Lista de Parámetros excesiva

56 Características de la Envidia

57 Cuando una entidad como una clase o método están más interesados en el comportamiento de otra entidad se le denomina envidia. La envidia viola el principio de diseño de la cohesión y eleva el acoplamiento. Envidia

58 Envidia La envidia se presenta sobre todo con los datos (atributos).
La solución generalmente implica utilizar move method cuando todo el método es envidioso. Envidia

59 Si una sola parte de un método o clase es envidiosa se debe utilizar extract method.
Si se presenta envidia con muchas entidades se deberá escoger aquella que sea la más fuerte para colocar en ella el método. Envidia

60 Actividad: del código de la criba se deberá reestructurar de la siguiente forma:
Nótese que el método generarCriba es muy grande por lo que deberá simplificarse utilizando Extract Method de la siguiente forma: Actividad

61 Encuentre las funcionalidades y extraiga 3 métodos: inicializarCandidatos(max), eliminarMultiplos(), obtenerCandidatosNoEliminados(); Haga los ajustes necesarios y verifique que otras partes del código se pueden reestructurar. Actividad

62 Sentencias Switch

63 Sentencias Switch La estructura switch causa generalmente duplicidad en el código. En general en POO debemos utilizar polimorfismo para hacer más legibles e intuitivos los códigos.

64 Sentencias Switch Generalmente se aplica los refactoring Extract Method y Move Method aunque en otros casos aplican refactoring más elaborados como: Replace Type Code with Subclasses, Replace Type Code with State/Strategy, Replace conditional with Polimorphism, entre otros.

65 Jerarquía de Herencias Paralelas

66 Jerarquía de Herencia Múltiples
Es un caso especial de Shotgun Surgery. La “cirugía de escopeta” se da cuando al modificar una clase se tienen que modificar otras clases en forma de cadena Jerarquía de Herencia Múltiples

67 Jerarquía de Herencias Paralelas
Este mal olor se caracteriza por que cada vez que se crea una sublcase de una clase x, se debe crear otra subclase de otra clase, que generalmente tiene el mismo prefijo que la otra jerarquía. Jerarquía de Herencias Paralelas

68 Jerarquía de Herencias Paralelas
Para solucionar este mal olor se debe utilizar refactroings como Move Method o Move fields para quitar las referencias de la otra subclase creada. Jerarquía de Herencias Paralelas

69 Reingeniería de Software
La refactorización es parte importante del proceso de reingeniería. La reingeniería es una actividad de reconstrucción, preferible de realizar antes de que se “derrumbe” la obra.

70 Técnicas de Reingeniería
Análisis de Inventario Reestructuración de Documentos INGENIERÍA INVERSA Reestructuración de Códigos Reestructuración de Datos Ingeniería directa

71 Ingeniería Inversa Se aplica para obtener un modelo detallado de análisis, ingeniería de requerimientos, diseño y en algunos casos implementación teniendo una solución. Es una actividad penada por la ley

72 Ingeniería Inversa Los archivos ejecutables pueden ser desemsamblados obteniendo su código fuente en ensamblador. Los archivos ejecutables con código portable (Java, .NET) pueden ser desemsamblados para obtener su código fuente.

73 Ingeniería Inversa Existen herramientas como los decompiladores que a partir de un código objeto pueden obtener código fuente. Todas las aplicaciones nativas se descomponen en instrucciones en ensamblador.

74 Ingeniería Inversa Sólo se puede obtener el código exacto si se conoce la técnica de generación de código objeto. En el caso de java existe un decompilador básico llamado javap o bien herramientas más avanzadas como cavaj, MacJAD o Java Decompiltaor, etc.

75 Ingeniería Inversa ¿Cómo se puede proteger nuestros códigos?

76 Ofuscación La ofuscación es una técnica avanzada de refactorización que permite a un código mantenerle obscuro (es decir no muy legible) con diversos propósitos de optimización. ¿No viola esto el principio de claridad en la implantación?

77 Ofuscación La ofuscación se realiza en muchas casos para hacer un código ilegible, también en muchos casos se puede reducir el tamaño del código fuente y del código binario realizado.

78 Ofuscación

79 Actividad Realizar la ofuscación del código Example de Martin Fowler
Refactoring de identificadores (métodos, clases, atributos) con nombres muy grandes y poco descriptivos. Agregando comentarios javadoc sin coherencia. Agregando funcionalidades no utilizadas así como código no útil.

80 La ofuscación al igual que el refactoring se puede hacer sobre las estructuras de datos.
Por ejemplo en arreglos: Téc, de Ofuscación La ofuscación es un arte. Hasta el momento la hemos realizado de forma manual y sin sistematización

81 Arreglos Tec. de Ofuscación

82 También se puede ofuscar clases:
Tec. de Ofuscación

83 Clases Tec. de Ofuscacion

84 Variables Tec de Ofuscación

85 Variables Tec. de Ofuscación

86 Sobre el flujo del programa
Tec. de Ofuscaciòn

87 Sobre el flujo del programa
Tec. de Ofuscación

88 Sobre el flujo del programa
Paralelización Tec. Ofuscación

89 Paralelización Tec. de Ofuscación

90 Paralelización Tec. de Ofuscación

91 Ciclos Tec. de Ofuscación

92 Ciclos Tec. de Ofuscación

93 Lo más adecuado es realizar la ofuscación sobre el código objeto generado sin alterar el original.
Existen ofuscadores como proguard, yguard que son libres o comerciales como Dasho o KlassMaster Téc. De Ofuscación

94 Actividad Comparar su proyecto ofuscado con el original a través de diff y patch Determina el grado de legibilidad de la aplicación calculado a través de la siguiente fórmula: Líneas negras / líneas blancas * 100 NÓTESE: LA OFUSCACIÓN NO HACE REUSABLE EL CÓDIGO PERO SI SEGURO

95 Lab De la página principal del sitio Web de su profesor: Realizar ofuscación de códigos para obtener el archivo más pequeño posible. Por ejemplo si la página es de 10KB y se reduce en 8KB es buena la ofuscación. Trate de eliminar líneas en blanco. La página NO debe de cambiar. Se premiará al que logre el menor tamaño posible con 1 PUNTO EXTRA. En caso de empate se anula.

96 Campos Temporales

97 Se presentan cuando existen variables o atributos de la clase subutilizadas.
Generalmente están allí debido a la utilización de algoritmos complicados. Campos Temporales

98 Se pueden utilizar refactorings como extract class o Introduce Null Objects
Campos Temporales

99 Encadenamiento de Mensajes

100 Encadenamiento de Mensajes
Este mal olor es muy notorio y se caracteriza por tener líneas de código en las que un objeto pide por otro y a su vez este por otro, y así sucesivamente logrando lo que se conoce como cadenas de mensajes Encadenamiento de Mensajes

101 Aparentemente se reduce el manejo de objetos temporales pero en realidad se está realizando mucho acoplamiento. Cualquier cambio en las relaciones internas provoca el cambio en las subsecuentes. Cadenas de Mensajes

102 Se pueden presentar el problema de “middle man” al tener muchos intermediarios.
La solución es en muchos casos aplicar Hide Delegate, Extract and Move Method. Cadena de Mensajes

103 Clases Alternativas con Distintos Mensajes

104 Se presenta cuando se tienen métodos similares en diferentes clases.
Generalmente se debe de renombrar el método, y en otros casos renombrarlo. Clases Alternativas

105 Librerías de Clases Incompletas

106 Librerías de Clases Incompletas
Las bibliotecas de clases aunque promueven el reuso de software, sino están bien elaboradas ocasionan muchos problemas. El problema radica en que la gran mayoría de las ocasiones, no se cuenta con el código de la biblioteca.

107 Librería de Clases Incompletas
Al no poseer el código fuente, se vuelve complicado realizar modificaciones. Se puede optar por los refactorings de Introducir Método Foraneo o Introducir Extesión Local

108 Actividad Desarrollar una biblioteca en Java que permita realizar operaciones básicas con vectores en dos y tres dimensiones. Para ello, se deberán construir “Beans” de la implementación.

109 Actividad Una vez construida la biblioteca deberá ser utilizada en un proyecto donde la funcionalidad sea utilizada por el usuario final. Se deberá documentar la biblioteca con comentarios JavaDoc.

110 Actividad Las operaciones a realizar son: Suma Resta Igualdad
Multiplicación por un Escalar Producto punto

111 Suma

112 Resta Producto Punto

113 Producto Vectorial Producto de un vector por un Escalar
Se multiplica el escalar por cada componente del vector kA donde k es un escalar y A un vector se tiene: kA= kA1x + kA2y + kA3z….

114 Existen diversas clasificaciones de malos olores
Existen diversas clasificaciones de malos olores. Una de las más populares es la Mika Mäntyla, el cual divide los malos olores en cinco categorías: Otros Malos Olores

115 1. Infladores Los que aumentan el tamaño del código como:
Método largo, clase larga Obsesión por tipos primitivos: aquí no se utilizan ADT cuando el tipo de dato lo requiere. Ejemplo: tipo de dato teléfono 1. Infladores

116 1. Infladores Lista de parámetros larga
Grupos de datos (dataclump): se presenta cuando se utilizan muchos datos aislados que podrían simplificarse utilizando un objeto o estructura para ello. 1. Infladores

117 2. Abusadores de POO Sentencias switch Campo temporal
Clases alternas con distintas interfaces Rechazo del legado: cuando una clase se reusa a utilizar su herencia. 2. Abusadores de POO

118 Cambio divergente: cuando se implementan en las clases funcionalidades diferentes al contexto de la clase Cirugía de escopeta Jerarquía de herencias paralelas 3. Impedidores de cambio

119 4. Los prescindibles Clases holgazanas
Clases de datos: cuando una clase sólo almacena datos pero no tiene métodos para acceder a ellos Código duplicado 4. Los prescindibles

120 Código muerto: código legado que ya no se utiliza en la versión actual del código.
Generalización especulativa: sucede cuando un código intenta solucionar problemas más allá de sus alcances originales. 4. Los prescindibles

121 5. Los emparejadores Alertan sobre alto acoplamiento de componentes.
Característica de la envidia Cadenas de mensajes Intermediarios 5. Los emparejadores

122 Intimidad inapropiada: ocurre cuando dos clases se conocen demasiado y se usan con demasiada confianza, el problema se presenta cuando esa relación en términos de POO es inapropiada. 5. Los emparejadores

123 Necesito de un software que permita llevar acabo el seguimiento de mis pacientes.
La secretaria debe poder agendar una cita y tener los datos de contacto del paciente (teléfono, domicilio, etc.) Hisoria de Usuario

124 Por mi parte, debo de poder realizar una cita clínica y poder imprimir una receta médica.
Las citas clínicas se van almacenando en un expediente electrónico para posteriormente visualizarlo Historia de Usuario

125 Laboratorio 5 Interacción 1: funcionalidad de agendar citas
Interacción 2: funcionalidad de captura de historia clínica y expedición de recetas Interacción 3: funcionalidad de consultar expedientes clínicos. Laboratorio 5

126 Lab 5 Programar la interacción que les corresponda.
Aspectos de diseño de interfaces de usuarios salen en segundo plano. Lab 5

127 Los malos olores dependen del autor aunque son consistentes.
Por ejemplo Jeff Bay en su artículo Object Calisthenics sugiere 9 reglas a seguir para construir software de calidad: Conclusiones

128 Conclusiones 1.Usa solo un nivel de indentación por método
2.No uses el “else” dentro de una condicional 3.Usa Wrappers para los tipos primitivos y las cadenas 4.Solo usa un punto por línea Conclusiones

129 Conclusiones 5.No abrevies 6.Mantén las entidades pequeñas
7.No utilices una clase que tenga más de 2 variables de instancia. Conclusiones

130 8.Una clase que contenga una colección no debe contener otras variables de instancia
9.No use propiedades, ni getters ni setters Conclusiones

131 ¿qué se tendría que hacer en el programa si la biblioteca utilizada realiza cálculos erróneos (por ejemplo manejar números complejos) y no se dispone del código fuente para modificarlo? Identificar mal olor Actividad

132 Actividad Librerías de Clases Incompletas
Solución: introducir método foráneo o introducir extensión local. Se puede utilizar el patrón de diseño adapatador Actividad

133 Dudas