Código fluído con refactorización: Volviendo a poner el “soft” en

software

ChileÁgilEmpower Agile 2010 - Todos los

derechos reservados

Sobre el oradorNombre: Danijel ArsenovskiExperiencia: programador, desarrollador, arquitecto de software, autor etc.Libros

RevistasVisual Systems Journal, Visual Studio Magazine, .NET Developers Journal, Infoq.com etc.

Participo en la comunidad Chile Ágil - www.chileagil.cl

“Soft” en SoftwareSoft (eng.) – blando, placido

"Se conoce como software1 al equipamiento lógico o soporte lógico de una computadora digital; comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos del sistema, llamados hardware. "

Wikipedia

Pregunta: ¿Qué apareció primero Winamp o Mp3 player (dispositivo)?

Software debe ser fácil de

Software es complejoAlgunos mecanismos para combatir complejidad

Modularidad Dividir para vencerResolver un problema complejo dividiéndolo en mas problemas mas simplesPregunta:

¿Es mejor tener mayor numero de módulos mas finos o tener menos módulos con mayor cantidad de código?¿No significa mayor numero de módulos == mayor complejidad?

Modularidad existe en diferentes nivelesEstructura

Permite añadir valor semánticoEncapsulación

Disminuye cantidad de información con cual debemos trabajar (carga cognitiva)

ReutilizaciónDisminuye complejidad y tamaño

Extensibilidad

Cuando software deja de ser «soft»

¿Te ha tocado trabajar con software difícil de cambiar?

No sabes donde hay que modificar el códigoNo sabes si es el único lugar donde hay que modificar el códigoAl modificar el código, no tienes certeza si el programa va a fallar en alguna otra parteHay demasiadas dependencias internasNo hay un diseño claro Es difícil probar un módulo de forma aisladaEs difícil intercambiar una pieza con otra

Gran bola de lodo

¿Por qué software se vuelve «hard»?

Con tiempo adquiere Deuda técnicaCrecimiento no reguladoReparaciones expeditas y repetidas

Resulta enInformación duplicada y globalizadaEstructura erosionada

Mentalidad Quick and dirtyResultados inmediatos con visión de corto plazo

Si funciona, no lo toques¿Sabiduría de ingeniería, o es la señal de que ya no tenemos control?

A veces es necesario tomar el torro por las astas

Tarde o temprano, si solamente juegas para evadir…

¿Entonces, como mantener el «soft» en el software?

Pruebas automatizadas

Diseño

Refactorización

Ciclo de Refactorización

Descubre como «huele» (code smell) el códigoRefactoriza (eliminando el mal olor)Ejecuta las pruebas

Malos olores del código fuente

Metáfora para problema potencial en código.Es un síntoma.Es difícil imponer métricas o reglas exactas

¿Cual es el numero máximo de líneas que un método debe tener?¿Y numero mínimo?Herramientas de análisis estática de código fuente ayudan.. Pero hasta cierto punto.

Refactorización

Mejora el diseño No cambia comportamiento visibleSoftware sigue operando correctamenteSe puede automatizar¿Refactorización no es nada nuevo?Elimina malos olores

Desafío

Ejercicios con código legado

Detectar el mal olor

Proponer la solución (refactorización)

Detecta el mal olor

Comentarios

Comentarios mienten, código no miente Código se ejecuta, comentarios no

Llegan a ser obsoletos con facilidadSon buena señal que el código esta poco claro, demasiado complejo etc.Muchas veces son indicador de que un bloque de código merece ser un método apartePruebas unitarias son mejor alternativa para documentar el código

Refactorizaciones: Extraer método, Renombrar, Escribir prueba unitaria

Método largo

Difícil de modificar, mantener, depurarDifícil de entenderDifícil de reutilizar

Refactorizaciones: Extraer método, Convertir método a clase

Pregunta: ¿Cuál es el numero máximo de las líneas de código fuente para un método bien hecho?

Detecta el mal olor

Código duplicado; no cumple con OCP

Pregunta: ¿Qué es OCP (Open-Closed Principle)?Código duplicado es el peor de los oloresMuchas veces resultado de un simple COPY/PASTEHace que software es difícil de mantener: cambias código en un lugar, pero no sabes de copia en otro lugar. Hace que cantidad total del código sea mayorHace que software es difícil de entender; no es claro que cada copia debe representar o como se diferencian

Refactorización: Reemplaza código de tipo con polimorfismo

Detecta el olor

Clase de datos

¿Data sin comportamiento?Comportamiento debe estar en alguna otra parteJuega contra encapsulación y estructuración A veces acompañado por olor de «Intimidad inapropiada»

Refactorización: Mover método

Detecta el mal olor

Lista de parámetros larga, Aglomerado de datos

Pregunta: ¿Podrían ser algunos de los parámetros relacionados? ¿Cuáles?Método esta haciendo demasiado

Refactorizaciones: Extraer método, Convertir método a clase, Reemplazar aglomeración de datos con objeto

Detecta el mal olor

Numero mágico

…o constante de otro tipo escrita directamente en el cuerpo del métodoCódigo poco claro: ¿Qué representa el valor?Muchas veces puede ser duplicado¿Si constantes mágicas son iguales, representan mismo o diferente concepto?

Código heredado

TDD: Código sin pruebas automatizadas es heredado (legado).

Introducir pruebas unitarias «post-factum» es complicadoNecesitamos pruebas automatizadas bien elaboradas para asegurarnos de que nuestros cambios no introducen bugsInyección de Dependencia, mocks, stubs y spies al rescate!

Red de objetos

¿Y los colaboradores?

¿Y que es …

Inyección de dependencias?Mocks?Stubs? Spies?Stubs parciales?

¿Cómo introducir pruebas unitarias en proyectos legados?

Necesitamos aislar modulo (método)Si pruebas abarcan demasiado, no nos ayudan descubrir el raíz del problemaColaboradores

Inyección de dependencias permite reemplazar colaboradores con stubs que tienen comportamiento conocido y predefinido Mocks permiten verificar interacción con el colaborador que deja efectos segundarios no directos.

Clase larga con métodos largosEspías permiten introducir implementación falsa al parte de la clasePrueba unitaria ejercita el espía, donde el método bajo prueba es real, pero los otros métodos llamados por este método real son falsos

Ejemplo practico

Literatura

ContactoNombre: Danijel ArsenovskiBlog: http://blog.refactoringin.netSitio:www.empoweragile.comCorreo electrónico: danijel.arsenovski at empoweragile.comLinkedIn:http://cl.linkedin.com/in/danijelarsenovskiFacebook:Danijel Arsenovski

¿Preguntas?