wuolah-free-TEMA-3-gulag-free_removed.pdf

Escribir unidades de código simples ▪ ▪ Branch points: o if, switch case, &&, || while, for, foreach catch Causas de la complejidad o Bloques de código pegados: Técnica Extract Method o Evitar el uso del switch mediante el uso de estructuras de datos o If-then-else anidados: ▪ REPLACE NESTED CONDI...

Escribir unidades de código simples ▪ ▪ Branch points: o if, switch case, &&, || while, for, foreach catch Causas de la complejidad o Bloques de código pegados: Técnica Extract Method o Evitar el uso del switch mediante el uso de estructuras de datos o If-then-else anidados: ▪ REPLACE NESTED CONDITINAL WITH GUARD CLAUSES ▪ DESCOMPOSICIÓN DE CONDICIONALES o Evitar el uso del switch mediante el uso de estructuras de datos ▪ Solución: usar EEDD Map que asocie las banderas: Técnica de descomposición de condicionales ▪ ▪ Problema: una sentencia condicional compleja Solución: o 1. Extraer la condición en un método propio/nuevo o 2. Extraer la parte del then y la parte del else en sus propios métodos Replace Nested Conditional with Guard Clauses (Sustituir condicional anidado por cláusulas de guarda) ▪ ▪ Problema: If anidados - dificultan el seguimiento de la ejecución del método. Solución: Usar guard clauses (sentencias booleanas). Técnica de descomposición de condicionales 3. Escribir código una vez – evitar duplicados ▪ ▪ ▪ ▪ ▪ Número uno de los bad smell!! Código duplicado (clones): o Dos fragmentos de códigos ideáticos (textual o sintácticamente) de al menos 6 líneas de longitud. o Tipo 1 (textualmente): Dos o más fragmentos de códigos idénticos textualmente de al menos 6 líneas de largo. El código duplicado puede estar en el mismo método, en métodos diferentes de la misma clase o en clases diferentes. o Tipo 2 (sintácticamente): Fragmentos idénticos sintácticamente. Difieren en comentarios, nombres de identificadores y literales. Problemas que plantea: o Difícil de localizar. No saber dónde hay otra copia del código, cuántas copias existen y dónde se encuentran. o ¿Y si el código duplicado contiene un bug? En caso de cambios, implica arreglar los bugs en múltiples lugares. El problema de la duplicación es no saber dónde hay otra copia del código, cuaÃÅntas copias existen y dónde se encuentran Escribir código reutilizable, genérico y llamar a métodos ya existentes. Técnica de refactorización: EXTRACT METHOD 4. Mantener las interfaces pequeñas ▪ ▪ ▪ ▪ Listas largas de parámetros son difíciles de comprender y mantener: su uso se vuelve inconsistente y difíciles de usar Limitar el número de parámetros por unidad a 4. Las listas cortas de parámetros son más faciales de reutilizar y menos expuestas al error. Técnicas de Refactorización: o INTRODUCE PARAMETER OBJECT o PRESERVE WHOLE OBJECT o REPLACE PARAMETER WITH METHOD 5. Separación de asuntos (Separation of concerns) ▪ ▪ ▪ ▪ Principio que afecta al diseño y las relaciones entre CLASES Evitar módulos (clases) grandes para lograr un acoplamiento débil entre módulos Motivación: o Uno de los objetivos de un buen diseño de clases es facilitar la localización de los cambios o Las modificaciones en una clase deberían tener efectos mínimos sobre las otras clases o Los cambios en un código débilmente acoplado son más fáciles de supervisar y ejecutar que los cambios en un código muy acoplado. Asignar responsabilidades a módulos separados y esconder los detalles de implementación detrás de las interfaces: o o ▪ Evitar definir campos públicos Definir claramente la interfaz de uso de la clase como un conjunto de métodos públicos. Cada clase debe representar una sola entidad bien definida, con responsabilidades bien definidas o La clase que posee unos datos tiene que ser responsable de procesarlos o Separar la clase: si la clase tiene más de una responsabilidad, dividir la clase en varias. 6. Componentes arquitectónicos débilmente acoplados ▪ ▪ ▪ Tratar de obtener nivel de acoplamiento débil entre los componentes de alto nivel. ¿Como? Minimizar la cantidad de código relativo entre módulos que está expuesto a módulos de otros componentes (información compartida entre módulos y llamadas) Los componentes independientes facilitan el mantenimiento aislado. 7. Mantener los componentes arquitectónicos equilibrados ▪ ▪ Equilibrar el número y tamaño relativo de los componentes de alto nivel del coÃÅdigo. Organizar el código de manera que el número de componentes se encuentre entre 612 y sean de tamaños similares. 8. Mantener la base de código pequeña ▪ ▪ ▪ ▪ Mantener la base de código tan pequeña como sea posible o Evitar el crecimiento de la base del código fuente, reducción activa del tamaño del sistema. Efectos adversos del tamaño en sistemas software Medidas funcionales: o E vitar el síndrome del lavadero (arrastramiento del alcance, scope creep), las funcionalidades y requisitos deseables. o Estandarizar la funcionalidad: evitar implementaciones de una misma funcionalidad de varias maneras o diversos caminos de flujo de información. Médidas técnicas: o Evitar duplicidades en el código o Refactorizar o Usar librerías y frameworks de terceras partes. o Dividir un sistema grande en sistemas más pequeños: microservicios ▪ Microservicios: Arquitectura basada en microservicios es un enfoque de desarrollo de una aplicación como un conjunto de pequeños servicios, cada cual se ejecuta en su propio proceso y se comunica mediante mecanismos ligeros (p.e., APIs en HTTP). o Diseño modular: su propósito es dividir sistemas grandes en pequeñas partes. Presentan acoplamiento débil. o Los microservicios se pueden implementar de manera independiente así, como la gestión de sus cambios. o Los microservicios se pueden implementar en distintas tecnologías, lenguajes y plataformas. o Cada microservicio posee su propio almacenamiento de datos. o Los microservicios se comunican entre si a través de la red (REST). 9. Automatizar las pruebas ▪ Automatizar las pruebas del código ▪ Implementar pruebas automatizadas con un entorno de pruebas ▪ Java Junit 10. Escribir código limpio ▪ ▪ ▪ ▪ ▪ ▪ Evitar code smells Evitar ciertos comentarios: o Los comentarios denotan código ininteligible, apuntan a un concern aplicar Extract method), indican buenas intenciones... No dejar código inalcanzable (dead code) No usar identificadores largos Definir constantes de manera explícita Capturar las excepciones Refactorización ▪ Técnicas: ▪ Deuda técnica: o Es una metáfora para hacer el coste de la deficiencia de la calidad (interna) del software visible o La deuda técnica hace visible la diferencia entre: o o Si la deuda técnica no se reduce o elimina, es más difícil implementar cambios en el futuro (el software es menos mantenible y es más difícil de evolucionar) – incrementa la entropía del software Para cuantificar la deuda se utilizan dos conceptos: ▪ Principal: coste de eliminar o reducir el impacto de un elemento de deuda técnica en un sistema software en un momento dado ▪ Interés: coste recurrente de no eliminar un elemento de deuda técnica sobre un cierto período de tiempo ▪ Principal: ej. coste de refactorizar ▪ Interés: coste del mantenimiento en el futuro ▪ También se puede tener en cuenta el time-to-market, es decir, la necesidad de lanzar nuevas versiones