1.36k likes | 1.55k Vues
“Bad Smells” en código. M.C. Juan Carlos Olivares Rojas. Febrero 2011. Agenda. Código Duplicado Métodos grandes Clases grandes Lista de Parámetros excesiva Características de la “envidia”. Agenda. Sentencias Switch Jerarquías de Herencia Paralelas Campos Temporales
E N D
“Bad Smells” en código M.C. Juan Carlos Olivares Rojas Febrero 2011
Agenda • Código Duplicado • Métodos grandes • Clases grandes • Lista de Parámetros excesiva • Características de la “envidia”
Agenda • Sentencias Switch • Jerarquías de Herencia Paralelas • Campos Temporales • Encadenamientos de mensajes
Agenda • Clases alternativas con diferentes interfaces • Librerías de clases incompletas
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
Criterios de Evaluación • 70% Examen práctico • 30% Desarrollo de portafolio de evidencias (trabajos, tareas y prácticas)
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
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
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
Es el principal indicador de un malor olor. • ¿cómo detectamos código duplicado? 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
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
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
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
En un diagrama de clases en UML es posible verificar algunos indicadores de malos olores y poder reestructurarlos antes de codificarlos. Mal Diseño
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
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
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
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
¿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
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
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
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
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
Singleton public class Singleton { private static Singleton INSTANCE = null; private Singleton() {} private synchronized static void createInstance() { if (INSTANCE == null){ INSTANCE = new Singleton(); } }
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
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 e-mail antes de las 13:00 horas.
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
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 Métodos grandes
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
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
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?
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.
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.
Antipatrón BLOB • Mejor conocido como “objeto todopoderoso”. Se presenta cuando una clase es muy grande tanto en atributos y/o en métodos.
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.
Antipatrón BLOB • Algunos autores consideran al Singleton (Simplicidad) un ejemplo de un antipatrón ¿por que?
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.
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.