Taller SOLID Refactor

SOLID Refactor (o cómo saber si refactorizar o no)

¿Qué haces tú aquí? (o quién soy y por qué me decidí a hacer esta charla)

Me presento Enrique Amodeo
Me dedico al software
> 10 años de experiencia
Desarrollo y arquitectura de software
Consultoría y formación
> 4 años haciendo agilismo
Mail: [email_address]
Blog: http://eamodeorubio.wordpress.com/
Sígueme, leches: @eamodeorubio
Con esta pose saldré más guapo

Hace un tiempo…

Refactor: Qué y Por qué

¿Qué es refactor?
Es una transformación de código
No altera la funcionalidad del software
Pero sí el diseño

¿Qué es refactor?
Es una transformación de código
No altera la funcionalidad del software
Pero sí el diseño
¿Y esto para qué sirve?

¿Qué es refactor? Parte integral del ciclo de TDD TDD sin refactor no asegura calidad Después de un refactor pasar test para asegurarse que no se cambió la funcionalidad Requisito / Tarea / Bug Escribir Test Unitario ¿Pasa Test? Refactor ¿Necesita Refactor? Luces Verdes! SI NO SI Escribir / Arreglar Código Aplicación Ejecutar Test NO

¿Cuando tengo que refactorizar? Requisito / Tarea / Bug Escribir Test Unitario ¿Pasa Test? Refactor ¿Necesita Refactor? Luces Verdes! SI NO SI Escribir / Arreglar Código Aplicación Ejecutar Test NO

¿Cuándo tengo que refactorizar?
El código no es de suficiente calidad
Tienes tiempo (cuidado con el timebox)
El beneficio en calidad compensa el coste

¿Cuándo tengo que refactorizar?
El código no es de suficiente calidad
Tienes tiempo (cuidado con el timebox)
El beneficio en calidad compensa el coste
¿Calidad? No quiero liarme con plugins, métricas y demás

Midiendo la calidad a ojo: SOLID y DRY (o cómo saber si el código es bueno de un vistazo)

Calidad sin herramientas
Evaluar de un vistazo la calidad del código
Reglas prácticas de fácil aplicación
Reglas sencillas y claras para evitar polémicas

DRY

DRY SOLID

DRY
Don’t Repeat Yourself
Pragmatic programmer
Evitar duplicación de información (en sentido amplio)
Código (copy&paste)
Datos
Documentación y comentarios
Elimina doble mantenimiento y sus costes y riesgos

SOLID
Tito Bob
Son en realidad 5 principios
S -> Single Responsibility
O -> Open Closed
L -> Liskov Substitution
I -> Interface Segregation
D -> Dependency Inversion

Single Responsability
Artefacto = método, clase, paquete…
Artefactos especializados en un responsabilidad
Promueve la alta cohesión
Evita el acoplamiento entre features y el código espagueti
Facilita la identificación del código a modificar ante un cambio/bug
Cada artefacto debe tener una única razón para cambiar

Open Closed
O sea, su comportamiento debe ser configurable
Promueve un diseño OO basado en un grafo de objetos configurable (GOOS)
Cooperación entre objetos
Bajo acoplamiento
Podemos añadir/modificar features sin modificar el código ya existente
Artefactos deben ser extensibles sin necesidad de modificar su código

Liskov Substitution
Asegurar el buen comportamiento de la herencia
Evitar el problema de la clase base frágil
No hacer “extends” sólo por similitud sintáctica
Los subtipos pueden debilitar las precondiciones y reforzar las postcondiciones
Promueve el uso de “interfaces”
Una instancia puede ser reemplazada por otra que sea de un subtipo y no causar bugs

Interface Segregation
O sea, las interfaces también se rigen por el principio de única responsabilidad
Promueven las Role Interfaces (GOOS)
Evitar interfaces sin una responsabilidad clara o que sirvan para todo
Alta cohesión
Muchas interfaces específicas son mejores que una única de propósito general

Dependency Inversion
Todas las dependencias deben estar al mismo nivel de abstracción
Puede ser el mismo o uno inmediatamente inferior al del artefacto en cuestión
Bajo acoplamiento
Extensibilidad (las abstracciones pueden tener muchas implementaciones)
No “romper” capas de arquitectura
Role Interfaces para representar abstracciones
Depender de abstracciones, no de cosas concretas

SOLID + DRY
Class-Responsability-Collaboration
Sinergia con el estilo GOOS de TDD
Diseño basado en grafos de pequeños objetos interconectados con role interfaces -> True OO
Configurable y extensible reemplazando los objetos por otros que cumplan las misma interfaces
1 cambio -> 1 interfaz y/o 1 clase

¡Que yo uso JS o Ruby! ¡ No tengo interfaces !
Class-Responsability-Collaboration
Colaboración -> Contrato entre dos partes -> protocolo
Interface es el conjunto de mensajes enviados/recibidos necesarios para cumplir tu parte del contrato
¡ No es una construcción JAVA !

¿Entonces qué pasa con el TDD? (o cómo engancha todo esto)

TDD Reloaded Requisito / Tarea / Bug Escribir Test ¿Pasa Test? Refactor ¡Pendiente para la próxima! SI NO SI Escribir / Arreglar Código Ejecutar Test NO ¿DRY & SOLID? ¿TENGO TIEMPO? FIN SI NO

TDD Reloaded Requisito / Tarea / Bug Escribir Test ¿Pasa Test? Refactor ¡Pendiente para la próxima! SI NO SI Escribir / Arreglar Código Ejecutar Test NO ¿DRY & SOLID? Test & Production code ¿TENGO TIEMPO? FIN SI NO

¿Q & A?

Manos a la obra

FizzBuzz
Recibes un entero y devuelves una cadena
Devolver “Fizz” si el número es divisible por 3
Devolver “Buzz” si el número es divisible por 5
Devolver “FizzBuzz” si es divisible por 5 y 3
Devolver “” si no es divisible ni por 5 ni por 3
TDD y Pair Programming
10 min.

Taller SOLID Refactor

by Agile Spain on Nov 06, 2011

Accessibility

Tags

Upload Details

Usage Rights

Statistics

Taller SOLID Refactor — Presentation Transcript