Post on 07-Jul-2015
description
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?