Volviendo a poner el “soft” en software
Upcoming SlideShare
Loading in...5
×
 

Volviendo a poner el “soft” en software

on

  • 1,027 views

Código fluído con refactorización: Volviendo a poner el “soft” en software. Presentación de Danijel Arsenovski en Agiles 2010, Lima.

Código fluído con refactorización: Volviendo a poner el “soft” en software. Presentación de Danijel Arsenovski en Agiles 2010, Lima.

Statistics

Views

Total Views
1,027
Views on SlideShare
601
Embed Views
426

Actions

Likes
0
Downloads
8
Comments
0

4 Embeds 426

http://www.empoweragile.com 286
http://agiles2010.agiles.org 123
http://empoweragile.com 9
http://www.linkedin.com 8

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • - Pedir todos que digan su nombre y algunas palabras
  • Trabajo como programador, desarrollador, arquitecto, jefe de proyecto, equipo etc. Publique libros, articulos Vengo de Chile, pero originalmente de otro pais Agustin y Philippe otros 2 oradores de Chile Ma ñana hablan de experiencia « Un terremoto, 120 voluntarios y 5 días para levantar un portal» Como me empecé interesar en Refactoring : trabajando en mantención de un software heredado Muchos aprendían código de memoria yo decidí aprender técnicas reutilizables
  • Cuando software deja de ser fácil de modificar, pierde su esencia. Software vs. Hardware
  • - Termino inventado por Kent Beck y Martin Fowler en su libro de Refactoring.
  • Los tradicionalistas se sorprenden cuando se dice que comentarios son mala cosa
  • Open Closed Principle: Closed for modification, open for extension.
  • Algunos dicen que ciertos programas son creaciones mas complejas hechas por hombre
  • Tipos de dobles xUnit patterns Fowler: Mocks aren’t Stubs

Volviendo a poner el “soft” en software Volviendo a poner el “soft” en software Presentation Transcript

  • Código flu í do con refactorización: Volviendo a poner el “soft” en software Empower Agile 2010 - Todos los derechos reservados
  • Sobre el orador
    • Nombre: Danijel Arsenovski
    • Experiencia: programador, desarrollador, arquitecto de software, autor etc.
    • Libros
    • Revistas
      • Visual Systems Journal, Visual Studio Magazine, .NET Developers Journal, Infoq.com etc.
    • Participo en la comunidad Chile Ágil - www.chileagil.cl
  • “ Soft” en Software
    • Soft ( eng. ) – blando, placido
    • "Se conoce como  software 1  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 complejo
    • Algunos mecanismos para combatir complejidad
    • Modularidad
      • Dividir para vencer
      • Resolver un problema complejo dividiéndolo en mas problemas mas simples
      • Pregunta:
        • ¿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 niveles
    • Estructura
      • Permite añadir valor semántico
    • Encapsulación
      • Disminuye cantidad de información con cual debemos trabajar (carga cognitiva)
    • Reutilización
      • Disminuye 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ódigo
      • No sabes si es el único lugar donde hay que modificar el código
      • Al modificar el código, no tienes certeza si el programa va a fallar en alguna otra parte
      • Hay demasiadas dependencias internas
      • No hay un diseño claro
      • Es difícil probar un módulo de forma aislada
      • Es difícil intercambiar una pieza con otra
    • Gran bola de lodo
  • ¿Por qué software se vuelve «hard»?
    • Con tiempo adquiere Deuda técnica
      • Crecimiento no regulado
      • Reparaciones expeditas y repetidas
    • Resulta en
      • Información duplicada y globalizada
      • Estructura erosionada
    • Mentalidad Quick and dirty
      • Resultados 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ódigo
    • Refactoriza (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 visible
    • Software sigue operando correctamente
    • Se puede automatizar
    • ¿ Refactorización n o 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 facilidad
    • Son 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 aparte
    • Pruebas 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, depurar
    • Difícil de entender
    • Difí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 olores
    • Muchas veces resultado de un simple COPY/PASTE
    • Hace 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 mayor
    • Hace 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 parte
    • Juega 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étodo
    • Có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 complicado
    • Necesitamos pruebas automatizadas bien elaboradas para asegurarnos de que nuestros cambios no introducen bugs
    • Inyecció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 problema
    • Colaboradores
      • 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 largos
      • Espías permiten introducir implementación falsa al parte de la clase
      • Prueba 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
  • Contacto
    • Nombre: Danijel Arsenovski
    • Blog:
    • http://blog.refactoringin.net
    • Sitio:
    • www.empoweragile.com
    • Correo electr ó nico:
    • danijel.arsenovski at empoweragile.com
    • LinkedIn:
    • http://cl.linkedin.com/in/danijelarsenovski
    • Facebook:
    • Danijel Arsenovski
  • ¿Preguntas?