Volviendo a poner el “soft” en software

1,065 views
1,028 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,065
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • - 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

    1. 1. Código flu í do con refactorización: Volviendo a poner el “soft” en software Empower Agile 2010 - Todos los derechos reservados
    2. 2. Sobre el orador <ul><li>Nombre: Danijel Arsenovski </li></ul><ul><li>Experiencia: programador, desarrollador, arquitecto de software, autor etc. </li></ul><ul><li>Libros </li></ul><ul><li>Revistas </li></ul><ul><ul><li>Visual Systems Journal, Visual Studio Magazine, .NET Developers Journal, Infoq.com etc. </li></ul></ul><ul><li>Participo en la comunidad Chile Ágil - www.chileagil.cl </li></ul>
    3. 3. “ Soft” en Software <ul><li>Soft ( eng. ) – blando, placido </li></ul><ul><li>&quot;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 . &quot; </li></ul><ul><li>Wikipedia </li></ul><ul><li>Pregunta: ¿Qué apareció primero Winamp o Mp3 player (dispositivo)? </li></ul>
    4. 4. Software debe ser fácil de
    5. 5. Software es complejo <ul><li>Algunos mecanismos para combatir complejidad </li></ul><ul><li>Modularidad </li></ul><ul><ul><li>Dividir para vencer </li></ul></ul><ul><ul><li>Resolver un problema complejo dividiéndolo en mas problemas mas simples </li></ul></ul><ul><ul><li>Pregunta: </li></ul></ul><ul><ul><ul><li>¿Es mejor tener mayor numero de módulos mas finos o tener menos módulos con mayor cantidad de código? </li></ul></ul></ul><ul><ul><ul><li>¿No significa mayor numero de módulos == mayor complejidad? </li></ul></ul></ul><ul><ul><li>Modularidad existe en diferentes niveles </li></ul></ul><ul><li>Estructura </li></ul><ul><ul><li>Permite añadir valor semántico </li></ul></ul><ul><li>Encapsulación </li></ul><ul><ul><li>Disminuye cantidad de información con cual debemos trabajar (carga cognitiva) </li></ul></ul><ul><li>Reutilización </li></ul><ul><ul><li>Disminuye complejidad y tamaño </li></ul></ul><ul><li>Extensibilidad </li></ul>
    6. 6. Cuando software deja de ser «soft» <ul><li>¿Te ha tocado trabajar con software difícil de cambiar? </li></ul><ul><ul><li>No sabes donde hay que modificar el código </li></ul></ul><ul><ul><li>No sabes si es el único lugar donde hay que modificar el código </li></ul></ul><ul><ul><li>Al modificar el código, no tienes certeza si el programa va a fallar en alguna otra parte </li></ul></ul><ul><ul><li>Hay demasiadas dependencias internas </li></ul></ul><ul><ul><li>No hay un diseño claro </li></ul></ul><ul><ul><li>Es difícil probar un módulo de forma aislada </li></ul></ul><ul><ul><li>Es difícil intercambiar una pieza con otra </li></ul></ul><ul><li>Gran bola de lodo </li></ul>
    7. 7. ¿Por qué software se vuelve «hard»? <ul><li>Con tiempo adquiere Deuda técnica </li></ul><ul><ul><li>Crecimiento no regulado </li></ul></ul><ul><ul><li>Reparaciones expeditas y repetidas </li></ul></ul><ul><li>Resulta en </li></ul><ul><ul><li>Información duplicada y globalizada </li></ul></ul><ul><ul><li>Estructura erosionada </li></ul></ul><ul><li>Mentalidad Quick and dirty </li></ul><ul><ul><li>Resultados inmediatos con visión de corto plazo </li></ul></ul><ul><li>Si funciona , no lo toques </li></ul><ul><ul><li>¿Sabiduría de ingeniería, o es la señal de que ya no tenemos control? </li></ul></ul>
    8. 8. A veces es necesario tomar el torro por las astas
    9. 9. Tarde o temprano, si solamente juegas para evadir …
    10. 10. ¿ Entonces, como mantener el «soft» en el software? <ul><li>Pruebas automatizadas </li></ul><ul><li>Diseño </li></ul><ul><li>Refactorización </li></ul>
    11. 11. Ciclo de Refactorización <ul><li>Descubre como «huele» ( code smell ) el código </li></ul><ul><li>Refactoriza (eliminando el mal olor) </li></ul><ul><li>Ejecuta las pruebas </li></ul>
    12. 12. Malos olores del código fuente <ul><li>Metáfora para problema potencial en código. </li></ul><ul><li>Es un síntoma. </li></ul><ul><li>Es difícil imponer métricas o reglas exactas </li></ul><ul><ul><li>¿Cual es el numero máximo de líneas que un método debe tener? </li></ul></ul><ul><ul><li>¿Y numero mínimo? </li></ul></ul><ul><ul><li>Herramientas de análisis estática de código fuente ayudan.. Pero hasta cierto punto. </li></ul></ul>
    13. 13. Refactorización <ul><li>Mejora el diseño </li></ul><ul><li>No cambia comportamiento visible </li></ul><ul><li>Software sigue operando correctamente </li></ul><ul><li>Se puede automatizar </li></ul><ul><li>¿ Refactorización n o es nada nuevo? </li></ul><ul><li>Elimina malos olores </li></ul>
    14. 14. Desafío <ul><li>Ejercicios con código legado </li></ul><ul><li>Detectar el mal olor </li></ul><ul><li>Proponer la solución (refactorización) </li></ul>
    15. 15. Detecta el mal olor
    16. 16. Comentarios <ul><li>Comentarios mienten, código no miente </li></ul><ul><ul><li>Código se ejecuta, comentarios no </li></ul></ul><ul><li>Llegan a ser obsoletos con facilidad </li></ul><ul><li>Son buena señal que el código esta poco claro, demasiado complejo etc. </li></ul><ul><li>Muchas veces son indicador de que un bloque de código merece ser un método aparte </li></ul><ul><li>Pruebas unitarias son mejor alternativa para documentar el código </li></ul><ul><li>Refactorizaciones: Extraer método, Renombrar, Escribir prueba unitaria </li></ul>
    17. 17. Método largo <ul><li>Difícil de modificar, mantener, depurar </li></ul><ul><li>Difícil de entender </li></ul><ul><li>Difícil de reutilizar </li></ul><ul><li>Refactorizaciones: Extraer método, Convertir método a clase </li></ul><ul><li>Pregunta: ¿Cuál es el numero máximo de las líneas de código fuente para un método bien hecho? </li></ul>
    18. 18. Detecta el mal olor
    19. 19. Código duplicado; no cumple con OCP <ul><li>Pregunta: ¿Qué es OCP ( Open-Closed Principle )? </li></ul><ul><li>Código duplicado es el peor de los olores </li></ul><ul><li>Muchas veces resultado de un simple COPY/PASTE </li></ul><ul><li>Hace que software es difícil de mantener: cambias código en un lugar, pero no sabes de copia en otro lugar. </li></ul><ul><li>Hace que cantidad total del código sea mayor </li></ul><ul><li>Hace que software es difícil de entender; no es claro que cada copia debe representar o como se diferencian </li></ul><ul><li>Refactorización: Reemplaza código de tipo con polimorfismo </li></ul>
    20. 20. Detecta el olor
    21. 21. Clase de datos <ul><li>¿Data sin comportamiento? </li></ul><ul><li>Comportamiento debe estar en alguna otra parte </li></ul><ul><li>Juega contra encapsulación y estructuración </li></ul><ul><li>A veces acompañado por olor de «Intimidad inapropiada» </li></ul><ul><li>Refactorización: Mover método </li></ul>
    22. 22. Detecta el mal olor
    23. 23. Lista de parámetros larga, Aglomerado de datos <ul><li>Pregunta: ¿Podrían ser algunos de los parámetros relacionados? ¿Cuáles? </li></ul><ul><li>Método esta haciendo demasiado </li></ul><ul><li>Refactorizaciones: Extraer método, Convertir método a clase, Reemplazar aglomeración de datos con objeto </li></ul>
    24. 24. Detecta el mal olor
    25. 25. Numero mágico <ul><li>… o constante de otro tipo escrita directamente en el cuerpo del método </li></ul><ul><li>Código poco claro: ¿Qué representa el valor? </li></ul><ul><li>Muchas veces puede ser duplicado </li></ul><ul><li>¿Si constantes mágicas son iguales, representan mismo o diferente concepto? </li></ul>
    26. 26. Código heredado <ul><li>TDD: Código sin pruebas automatizadas es heredado (legado). </li></ul><ul><li>Introducir pruebas unitarias «post-factum» es complicado </li></ul><ul><li>Necesitamos pruebas automatizadas bien elaboradas para asegurarnos de que nuestros cambios no introducen bugs </li></ul><ul><li>Inyección de Dependencia, mocks, stubs y spies al rescate! </li></ul>
    27. 27. Red de objetos
    28. 28. ¿Y los colaboradores?
    29. 29. ¿Y que es … <ul><li>Inyección de dependencias? </li></ul><ul><li>Mocks? </li></ul><ul><li>Stubs? </li></ul><ul><li>Spies? </li></ul><ul><li>Stubs parciales? </li></ul>
    30. 30. ¿Cómo introducir pruebas unitarias en proyectos legados? <ul><li>Necesitamos aislar modulo (método) </li></ul><ul><li>Si pruebas abarcan demasiado, no nos ayudan descubrir el raíz del problema </li></ul><ul><li>Colaboradores </li></ul><ul><ul><li>Inyección de dependencias permite reemplazar colaboradores con stubs que tienen comportamiento conocido y predefinido </li></ul></ul><ul><ul><li>Mocks permiten verificar interacción con el colaborador que deja efectos segundarios no directos. </li></ul></ul><ul><li>Clase larga con métodos largos </li></ul><ul><ul><li>Espías permiten introducir implementación falsa al parte de la clase </li></ul></ul><ul><ul><li>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 </li></ul></ul>
    31. 31. Ejemplo practico
    32. 32. Literatura
    33. 33. Contacto <ul><li>Nombre: Danijel Arsenovski </li></ul><ul><li>Blog: </li></ul><ul><li>http://blog.refactoringin.net </li></ul><ul><li>Sitio: </li></ul><ul><li>www.empoweragile.com </li></ul><ul><li>Correo electr ó nico: </li></ul><ul><li>danijel.arsenovski at empoweragile.com </li></ul><ul><li>LinkedIn: </li></ul><ul><li>http://cl.linkedin.com/in/danijelarsenovski </li></ul><ul><li>Facebook: </li></ul><ul><li>Danijel Arsenovski </li></ul>
    34. 34. ¿Preguntas?

    ×