Oct 24 2008

¿Comentarios en una refactorización perfecta?

Categoría: RefactorizaciónJuan @ 1:51 am

Más sobre refactorización en OOPSLA 2008…

En una presentación sobre refactorizar comentarios cuando se refactoriza código, Peter Sommerlad dijo lo siguiente:

Haciendo una buena refactorización los comentarios en el código son innecesarios

Totalmente en descuerdo.

La refactorización hace el código muchísimo más legible y claro (eso es indudable) y añadiendo los test unitarios tenemos incluso una mínima documentación (y, por supuesto, validación). Pero de ahí a decir que los comentarios son innecesarios (es más, el se refirio a ellos como contraproducentes) hay mucho camino.

Nunca he creído que haya que escribir muchos comentarios en el código. Con demasiados comentarios se obtene lo contrario a lo deseado (en este caso sí es contraproducenta como Sommerlad indica), es decir, ofuscación en lugar de claridad y un esfuerzo y tiempo extra por parte del desarrollador (los comentarios hay mantenerlos junto con el código).

Ahora bien, las partes más complejas del código (por ejemplo en un algorítimo, una compleja operación matemática, un tipo complejo de datos, etc) que no sean triviales a simple vista deberían llevar un mínimo de comentarios para ayudar a su comprensión y entendimiento puesto que la refactorización por si sola no da la suficiente información con los nombres de funciones, variables, métodos, clases, etc. Es más, creo también que un exceso de refactorización puede ser contraproducente ya que tener demasiados métodos de muy pocas líneas podría llegar a dificultar la claridad del código.

En resumen: Refactoriación, sí. Comentarios, también (los justos y necesarios, ni más ni menos)

Etiquetas: ,


Oct 23 2008

Miedo a las herramientas de refactorización

Categoría: RefactorizaciónJuan @ 3:49 am

Hace unas semanas trabajando con un desarrollador en un equipo le pregunté si utilizaba alguna herramienta de refactorización o lo hacía manualmente. El buen hombre me contestó (y esto ya lo he oído otras veces) que lo hacía manual ya que no se fiaba de las herramientas puesto que en cierta ocasión la refactorización fue errónea y perdió más tiempo en encontrarlo que si lo hubiera hecho a mano desde el principio

Por casualidad atendí a un workshop (lo llamaré “taller” de ahora en adelante) sobre refactorización en OOPSLA y entre muchas otras cosas hablaron de por qué los desarrolladores no terminaban de usar las herramientas de manera extensiva. Se especulo sobre la calidad de las herramientas, la facilidad de uso, el hábito de los desarrolladores, la velocidad de hacerlo con la herramienta vs. hacerlo a mano, los tipos de refactorización que la herramienta puede hacer, la capacidad de respetar los comentarios y los espacios en blanco y, por supuesto, de lo confiables son (y otras que seguro me he dejado en el tintero).

En el taller se fueron más hacia el hábito de los programadores, la facilidad de uso y lo “bonito” que queda la herramienta en pantalla. Sin embargo yo creo que el problema fundamental es otro.

Una herramienta se utiliza cuando hace el día a día mucho más fácil a la persona que lo utiliza, es decir, la herramienta es capaz de solucionar un problema que el usuario tiene de una manera más fácil, con menos tiempo y con menor esfuerzo. Si la herramienta no es lo suficientemente buena, está incompleta, sólo es aplicable a ciertos casos, es dificil de manejar, etc., esta no se llegará a usar por el usuario.

En este caso concreto creo que las herramientas de refactorización no están lo suficientemente avanzadas todavía y tiene mucho camino por delante hasta llegar a ser herramientas imprescindibles para el programador. Lo más importante es que no cubren todos los tipos de refactorizaciones (y esto lleva al usuario a tener que hacer algunas manuales con lo que si hace una, ¿por que no hacer otras?) y, sobre todo, es que no son seguras al 100% en algunos tipos de refactorizaciones que son capaces de hacer.

Para dejarlo meridianamente claro, el tema aquí es si usar refactorización automática mediante herramientas de refactorización y no el hacer refactorización en sí ya que esto debería ser el “pan nuestro de cada día”. Refactorizar, es decir, hacer el código más limpio, claro, manejable y mantenible (mejorarlo a grandes rasgos) debería ser obligatorio cada vez que se escribe, reescribe o se mantiene código. Y, por supuesto, no olvidarlo como una parte fundamental de TDD (Test Driven Development) ya que este no se acaba al obtener la “luz verde”.

Etiquetas: , ,