Si bien este libro presenta un catálogo de escenarios o casos sobre los que es un código poco sano se refactoriza a un patrón de diseño, lo más interesante para mi es el enfoque con el que se trata el tema. Cuando construimos software muchas veces no se tiene claro cual es el alcance. Las metodologías ágiles, XP, asumen esto como una regla del juego y se organizan en función del cambio. Una frase muy conocida al respecto es "Lo único constante en el desarrollo de software es el cambio".
El libro introduce 2 ideas que dan claridad al problema de diseñar una aplicación: la sobre ingeniería, que vendría a ser como matar un mosquito con un misil tele dirigido, y la sub ingeniería, donde el problema radica en que la complejidad del código pasa a ser una limitación importante a la hora de modificar una aplicación. De alguna manera, diseñar implica encontrar un equilibrio entre estos dos caminos para lidiar con la complejidad y el cambio. Por lo que es necesario diseñar a lo largo de todo el proyecto.
Qué es refactorizar?
Refactorizar es mejorar el diseño de un código existente. Y también una estrategia de construcción muy eficaz. Podemos comenzar a construir una aplicación, de la manera más simple posible, y refactorizarla a medida que entendemos mejor su contexto y alcance. Esta idea, tomada del mundo XP, fue para mi en un proyecto pasado, una estrategía que resultó clave para llegar a buen puerto. Por lo general no se encuentra el diseño adecuado en el primer intento. De hecho, es bueno darse un tiempo para probar una idea y aprender.
Para qué Refactorizar?
- Para simplificar el código y responder mejor a los cambios.
- Para aprender a lidiar con la complejidad en un entorno cambiante.
- Para hacer el esfuerzo justo.
- Para potenciar al equipo, es muy didactico refactorizar de a pares, mejora los skills de programación de todos.
- Para simplificar. Lo simple es mágico, todo es más fácil cuando es más simple.
Cuando refactorizar?
Esta es quizás la pregunta más difícil de responder, ya que depende del caso. Si se refactoriza demasiado tarde, puede ser muy costoso. Demasiado temprano, puede ser que todavía no conocemos suficiente del problema. Pero hay ciertas cosas que podemos oler, que nos dan una idea sobre piezas de la aplicación que no son sanas:
- Esto es difícil de entender (complejo).
- Siempre lleva mucho tiempo modificar esto (rígido ante cambios).
- Cuando tocamos esto, surgen bugs que no detectamos.
- Es difícil de testear.
Una lista de cosas que huelen mal en el código:
Refactorizar es como invertir en la salud de la aplicación. Tiene un efecto que mejora las condiciones de éxito. Una buena práctica es ir agregando los casos encontrados al backlog y priorizarlos junto como un ítem más en función de las necesidades del negocio.
Cómo refactorizar?
Hay muchas técnicas que ayudan a hacer refactoring efectivamente, como TDD, inyección de dependencias, patrones de diseño, herramientas de refactoring (resharper, eclipse), catálogo de refactoring, etc. Además es importante entender porqué el código no es sano y cómo lo mejoraremos, invirtiendo el esfuerzo justo.
Un enfoque muy interesante del libro, es que para evaluar la solución de refactoring, propone distintos puntos de vista.
- Comunicación: De que manera el código comunica lo que hace.
- Duplicación: La duplicación hace que sea más fácil cometer errores. El código duplicado es más difícil de mantener => evitar la duplicación.
- Simplicidad: Cómo se puede hacer más simple? Para esto es muy importante encontrar el patrón de diseño adecuado.
Se me ocurren otros puntos de vista que se podrían agregar:
- Testeabilidad: Que tan fácil es de testear?
- Flexibilidad: Que tan fácil es de cambiar?
- Esfuerzo: Como llevaría menos esfuerzo?
Más links en delicious
saludos!
No hay comentarios.:
Publicar un comentario