Martin Fowler recientemente ha publicado un nuevo artículo sobre cómo aplicar refactoring en los desarrollos. Normalmente, se suele separar el desarrollo de nuevas características de las tareas de mejoras de una parte o partes del desarrollo, lo que provoca que, muchas veces, estas tareas de mejora quedan en la cola de la lista debido a exigencias de tiempo o desconocimiento de los responsables u otra índole.
La tarea de un desarrollador no implica simplemente codificar una solución y punto. Sino también crear pruebas de errores y documentación. Lo que Martin Fowler propone es incorporar las tareas de refactoring dentro del flujo de trabajo de un desarrollador incluyendo estas fases:
1.- TDD Refactoring
El famoso "Test Driven Development": primero haz las pruebas de tu nueva funcionalidad, luego codifica esta nueva funcionalidad para que la prueba pase y luego mejora tu código. Muchos equipos se esfuerzan en hacer TDD pero pocos lo acaban implantando bien ya que esto implica repetir varias veces el flujo (test falla, codificar para que la prueba no falle y mejora, y vuelta a empezar) lo que quiere decir más tiempo.
Sin embargo, por experiencia personal, los caminos rápidos siempre llevarán a más errores y a un código de poca calidad. Así que yo incluso añadiría una fase más dentro del TDD: piensa cómo va a ser usado tu código desde fuera. Este análisis te dará más pistas sobre cómo realizar las mejoras de tu nuevo código y fomentará el uso del TDD de verdad.
2.- Litter-Pickup Refactoring
Limpia tu código de forma que la siguiente vez que trabajes con él, no tengas que explicarle a nadie qué hace y se puedan introducir cambios más fácilmente. Por lo que, documenta los métodos, incluye comentarios, renombra funciones, etc.
3.- Comprehension Refactoring
Ya tenemos el código implementado y con pruebas que respaldan su funcionalidad. Además, has pensado bien el diseño de tu código y luce genial. Sin embargo, posiblemente llevas horas o días con este problema y estás viciado del mismo. Así que en esta fase te pondrás la gorra de otro desarrollador que ve por primera vez tu código. Martin Fowler lo dice en una frase que me encanta:
"Whenever you have to figure out what code is doing, you are building some understanding in your head. Once you've built it, you should move that understanding into the code so nobody has to build it from scratch in their head again."
En resumen, si lo que te imaginas en tu cabeza que hace, es lo que hace, perfecto, en caso contrario, haz que haga lo que te imaginas.
4.- Preparatory Refactoring
Esta y las siguientes tareas tienen que ver con mejoras que se podrían introducir a medio o largo plazo. Concretamente, en esta, el desarrollador debe pensar en tareas y mejoras que se deberían hacer cuando llegue una nueva tarea respecto al nuevo código.
5.- Planned Refactoring
Tareas que engloben distintas partes del sistema y que requieren tareas dedicadas.
6.- Long-Term Refactoring
Tareas que requieran de varios ciclos de desarrollo por su envergadura o complejidad.
http://martinfowler.com/articles/workflowsOfRefactoring/
No hay comentarios:
Publicar un comentario